SQL: implement downstream execution semantics for window frames

[zzylol]

Summary

PR #270 makes DataFusion window-frame semantics lossless in the canonical pre-ASAP IR: SQLWindowFunc.frame now carries resolved ROWS and RANGE units and bounds. Nothing downstream currently interprets that field, so the planner can preserve a frame but cannot yet bind or execute its behavior.

This affects frame-sensitive functions including SUM, AVG, COUNT, MIN, MAX, FIRST_VALUE, LAST_VALUE, and NTH_VALUE, plus the distinct ClickHouse lagInFrame and leadInFrame variants introduced by #267.

Scope

• Define the post-ASAP/physical representation of SQL window frames.
• Carry the canonical frame through binding and physical planning.
• Implement or integrate execution for resolved default and explicit ROWS/RANGE frames.
• Define how legacy frame: None IR is handled; it must not be assigned one static default because DataFusion defaults depend on whether ordering is present.
• Return a clear unsupported error at the execution boundary for any frame unit or bound that remains unimplemented.

Semantic requirements

Execution should match the pinned DataFusion behavior used during SQL lowering, including:

• context-dependent default frames with and without ORDER BY;
• finite, current-row, and unbounded preceding/following bounds;
• RANGE peer behavior and numeric versus interval offsets;
• ordering direction and null ordering;
• frame-insensitive ANSI ranking/navigation functions continuing to ignore the frame;
• lagInFrame and leadInFrame respecting it.

Acceptance criteria

• Representative frame-sensitive queries produce results matching DataFusion for default and explicit ROWS/RANGE frames.
• A non-default frame is observably different from the default where SQL semantics require it.
• Legacy frame: None is handled explicitly and safely.
• End-to-end tests demonstrate the frame survives pre-ASAP IR, physical planning, and execution.

GROUPS representation/lowering is tracked separately in #280.

Related

• SQL: ClickHouse's lagInFrame window function needs window-frame modeling #231
• SQL: lagInFrame/leadInFrame need distinct WindowFuncKind variants, not Lag/Lead #267
• SQL: SQLWindowFunc doesn't model window frames (ROWS/RANGE ... PRECEDING/FOLLOWING) #268
• SQL: model GROUPS window frames #280
• PR feat(frontend-sql): model SQL window frame clauses (ROWS/RANGE BETWEEN ...) #270

[zzylol]

Related open work

• Implements downstream execution after the frame representation introduced for SQL: ClickHouse's lagInFrame window function needs window-frame modeling #231.
• Depends on SQL: model GROUPS window frames #280 for GROUPS frame representation; ROWS/RANGE work can proceed independently.
• SQL: ClickHouse's lagInFrame window function needs window-frame modeling #231 remains the function-specific lagInFrame motivation.