docs: a window aggregate's rid is chunk-relative, not a partition row

The per-row window callback's `rid` was documented as the output row's index
within the partition (AggregateWindowRequest, AggregateFunction.window(),
AggregateClient.window()). It is not: DuckDB's WindowCustomAggregator
evaluates one output chunk at a time and calls the callback with `i`, the
row's index within that chunk (0 <= i < STANDARD_VECTOR_SIZE); the partition
row is `row_idx + i`, which the per-row callback never receives. The
extension forwards DuckDB's value untouched (it is also the index it copies
the result into), so a worker that used `rid` to index the partition read the
wrong rows past the first chunk.

The frames were always partition-relative, and they are what a worker must
use. The batched path is unchanged and correctly documented: its `row_idx`
is the partition row of the first output row, and the default window_batch()
passes partition rows to window() — so `rid` now says it identifies the row
and must not be used to index the partition.

Docstrings are outside the protocol hash, so no port's reflection changes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: rustyconover

vgi/aggregate_function.py

@@ -518,7 +518,14 @@ def window(
         """Compute the aggregate value for one output row.
 
         Args:
-            rid: Partition-local row index being filled.
+            rid: Identifies the output row being filled; do not use it to
+                index the partition. Over the per-row ``aggregate_window``
+                RPC it is DuckDB's own ``rid``: the row's index within the
+                current output chunk (``0 <= rid < 2048``), not its row in
+                the partition. When the default :meth:`window_batch` calls
+                this, it passes the partition row index instead. Either way
+                ``subframes`` are partition-relative: use them to find the
+                rows to aggregate.
             subframes: Frame ranges ``[(begin, end), ...]`` — 1 for the default
                 frame, 3 when ``EXCLUDE`` produces multiple subframes.
             partition: The cached partition data.

vgi/client/aggregate.py

@@ -371,7 +371,10 @@ def window(self, *, partition_id: int, rid: int, frames: Frames) -> pa.RecordBat
 
         Args:
             partition_id: The partition previously shipped by :meth:`window_init`.
-            rid: Row index within the partition of the output row being computed.
+            rid: Identifies the output row. The DuckDB extension sends DuckDB's
+                own per-row ``rid``, the row's index within the current output
+                chunk rather than its row in the partition; ``frames`` carry the
+                partition-relative bounds, and a worker must use those.
             frames: The row's subframes as ``(begin, end)`` half-open offsets
                 into the partition. One entry normally; two or three for
                 ``EXCLUDE TIES`` / ``EXCLUDE GROUP``.

vgi/protocol.py

@@ -2887,7 +2887,10 @@ class AggregateWindowRequest(ArrowSerializableDataclass):
         execution_id: Identifier for one query execution, stable across the
             coordinator and any secondary workers; keys worker-owned state.
         partition_id: Identifier of the window partition this call addresses.
-        rid: Row index within the partition for the output row being computed.
+        rid: Which output row this call fills, as DuckDB's per-row window callback
+            reports it: the row's index within the current output chunk
+            (``0 <= rid < STANDARD_VECTOR_SIZE``), NOT its row in the partition.
+            The frames below are partition-relative; use them to find the rows.
         frame_starts: Subframe start offsets (inclusive) within the partition, one
             per subframe.
         frame_ends: Subframe end offsets (exclusive) within the partition, parallel