Resolve the issue #15985

Background
The Core Problem: Shifting Input Field Counts. A LogicalWindow's expressions (RexNodes) can refer to two things via RexInputRef: (1) Columns from its input relation (index < inputFieldCount); (2) Literals from its constants list (index >= inputFieldCount).

When we chain the windows, the inputFieldCount for each subsequent window increases.

• Original Window: Input has N fields. A reference to the k-th constant is RexInputRef(N + k).
• First New Window (LW1): Input is the original input, so inputFieldCount is N. It adds agg1_count fields. Its output has N + agg1_count fields.
• Second New Window (LW2): Input is the output of LW1, so its inputFieldCount is now N' = N + agg1_count.

If a group in LW2 keep using the original RexInputRef(N + k), LW2 will interpret it as a reference to the (N + k)-th column of its input. This is now incorrect. It's pointing to one of LW1's aggregate results instead of the intended constant. The reference needs to be shifted to RexInputRef(N' + k).

Solution
Correct Row Type construction

• For each new LogicalWindow, we calculate its output RelDataType.
• The new type is built by taking all the fields from its input (currentInput.getRowType()) and appending the new aggregate fields that this specific group will produce.
• To ensure the final output schema is identical to the original, we get the field definitions (including names and types) for the new aggregate columns directly from the originalWindow's output row type. The cumulativeAggFieldCount variable correctly tracks our position in the original aggregate field list.

Correct RexInputRef pointing to the constant variable
Use a RexShuttle to traverse the expressions in each Window.Group and adjust any RexInputRef that points to a constant. Specially, visitInputRef is overridden. It checks if an input reference's index points to a constant (index >= originalInputFieldCount). If it does, it creates a new RexInputRef with the index increased by the shift amount. Otherwise, it returns the original reference. The shift amount denotes the number of new fields added by previous windows in the chain.

Why groupSet and orderKeys Don't Need Shifting
groupSet and orderKeys Refer To: The integer indices in groupSet (PARTITION BY) and orderKeys (ORDER BY) refer to the columns of the window's direct input relation. Calcite provides mechanisms to fail early or eliminate the constant variables appearing in the window functions's Partition By or Order By. Therefore, these indices will always be < inputFieldCount and will never point to the constants list.

Outcome
Dataset: the Quick Start of COLOCATED_JOIN
Test SQL:

SET useMultistageEngine=true;
SET usePhysicalOptimizer=true;
SELECT
  userUUID,
  cityName,
  productCode,
  ts,
  tripAmount,
  sum(tripAmount) over(partition by cityName order by ts asc ROWS BETWEEN CURRENT ROW and 2 FOLLOWING) as amount_post_2_city,
  lag(tripAmount, 1, '0') OVER (partition by cityName order by ts asc) AS prev_amount_city,
  tripAmount-prev_amount_city as diff,
  row_number() over(partition by cityName order by ts asc) as row_city,
  sum(tripAmount) over(partition by productCode order by ts asc ROWS BETWEEN 1 PRECEDING and CURRENT ROW) as amount_pre_1_productCode,
  row_number() over(partition by productCode order by ts asc) as row_productCode
FROM
    userFactEvents
WHERE
    ts <= 1735696010 
    AND ts > 1735689810 
    AND cityName IN ('Chicago', 'New York')

Removing SET usePhysicalOptimizer=true; get the same correct result.

Result