[Story][FEA] Complete grouped over expression coverage in cuDF-Polars

Grouped `over(...)` expressions are implemented in cuDF-Polars using a forward-shuffle / local-evaluate / backward-shuffle execution model. This issue tracks remaining grouped-`over` API coverage that can use that model before we tackle long-term huge-group execution where one group may need to span multiple partitions/ranks.

Initial child issues / feature areas:
- Support `rolling_*_by(...).over(...)`: https://github.com/rapidsai/cudf/issues/23591
- Support `rolling(...).over(...)`: https://github.com/NVIDIA/cudf/issues/23623
- Support cumulative grouped-over variants such as `cum_min().over(...)`, `cum_max().over(...)`, `cum_prod().over(...)`, and `cum_count().over(...)`
- Support `pct_change().over(...)`
- Reduce grouped-over boilerplate by sharing implementation/decomposition logic across order-sensitive expressions

Example:

```python
def test_cum_max_over(engine: GPUEngine) -> None:
lf = pl.LazyFrame(
{
"g": ["A", "A", "A", "B", "B"],
"t": [1, 2, 3, 1, 2],
"x": [10, 30, 20, 5, 15],
}
)

q = lf.select(
pl.col("x").cum_max().over("g", order_by="t").alias("x_cum_max")
)
assert_gpu_result_equal(q, engine=engine)
```

**Note**: This issue is about near-term grouped `over(...)` API coverage. Full distributed execution for low-cardinality / huge-group cases can be tracked separately under the broader grouped range-window or streaming ordered-window work.