Window accumulator memory is not accounted by WindowOperator

WindowOperator reserves memory only for its own PagesIndex (WindowOperator.java — memoryContext.setBytes(pagesIndexWithHashStrategies.pagesIndex.getEstimatedSize().toBytes())). The memory held by window accumulators themselves is never reported to the memory pool.

This matters most for aggregation window functions with ORDER BY or DISTINCT:

• OrderedWindowAccumulator buffers its input in an internal PagesIndex and replays it into the delegate on output, so it holds the full buffer plus the growing delegate at the same time.
• DistinctWindowAccumulator holds a distinct hash and its own PagesIndex.

None of that state is visible to the memory pool, so a query like array_agg(DISTINCT x ORDER BY x) OVER (...) over a large partition can exhaust worker heap without the per-node memory limit or the low-memory killer engaging — the same failure mode fixed for regular aggregations in #31039, but on a different surface: the window operators do not track accumulator state at all (not just the transient replay peak), so the fix is more than threading an UpdateMemory callback through.

Relates to #31039.