Table: expose row position to plugins (aria-rowindex) so useTableRowIndex avoids its own index map

### Context

Follow-up from review of #3756 (`useTableRowIndex`).

`useTableRowIndex` currently has to build its own `item → index` map because `renderCell(item)` receives **only the row item** (no position) and runs during render — there's no row index available at derive time. The plugin works around this by taking the rendered `data` array and computing a memoized single-pass lookup.

### Proposal

If the Table exposed the row's position to plugins — e.g. via `aria-rowindex` on the `` (or a `rowIndex` passed into the cell render path) — the plugin could read it directly instead of maintaining its own map. That would:

- **Reduce the plugin's API surface** — no need to pass `data` / `getRowKey` into `useTableRowIndex` just to recover position.
- Avoid the extra bookkeeping pass entirely.
- Keep a single source of truth for row position (ties into #3939 — the ARIA row index).

### Notes

- `transformBodyCell` receives `columnIndex` but not `rowIndex` today; `transformBodyRow` gets `rowIndex` but the index column renders via `renderCell`. Exposing the row position on the cell render path (or letting the plugin read the rendered `aria-rowindex`) would close the gap.
- Pairs with #3939 (ARIA row index as a table-level concern).

_Raised from @cixzhang's review comment on #3756._