BUG: fix Table.group_by().groups.aggregate() for multidimensional columns - #20410

Description

ColumnGroups.aggregate() (used by Table.group_by(...).groups.aggregate()) has a fast path for np.mean that does:

vals = np.add.reduceat(par_col, i0s) / np.diff(self.indices)

np.diff(self.indices) is a 1-D array of per-group row counts. For a multidimensional column, np.add.reduceat(par_col, i0s) has shape (n_groups, *trailing_dims), and dividing it by the 1-D counts array broadcasts against the last axis instead of the row axis. This means:

• if n_groups happens to equal a trailing dimension size, the division silently succeeds but produces wrong numbers, with no error or warning at all;
• otherwise it raises a broadcasting error, which gets caught and turned into a warning, and the column is silently dropped from the aggregated table.

This fixes it by reshaping the per-group counts so the division only broadcasts against the row axis, preserving the trailing dimensions. It's the same underlying issue as #13225, which was already fixed for TimeSeries.aggregate_downsample() — this applies the same fix to the Table.group_by().groups.aggregate() code path.

Added a regression test covering both failure modes described above (wrong values when shapes coincide, dropped column otherwise), and a changelog fragment.

Fixes #20409

AI Disclosure

If AI tools were used to develop this pull request, describe the tools including specific model and version, how they were used, and what content is AI generated. Otherwise enter "N/A".

I used Claude Code (Claude Sonnet 5) as an assistant throughout this contribution:

• It helped search the codebase and identify the root cause in astropy/table/groups.py.
• I reviewed and ran the reproduction scripts myself to confirm the bug before filing the issue.
• The issue body, PR description text,

• I certify that I am human and that I take full responsibility for this pull request including all interactions with reviewers.

Merge method

• By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.