Lists: collaborative grid freshness poll and presence (`POST /api/lists/{id}/data/versions`)

[Adron]

Part of #49 — Lists parity gaps: GitHub-backed lists, saved views, view modes and collaborative editing

Unused API: POST /api/lists/{id}/data/versions — "Combined freshness poll and presence
heartbeat for the grid" — taking an optional focusedRowId.

Without it, two people editing the same list on Android silently clobber each other's rows.

• Heartbeat while a list is open, sending the focused row.
• Use the freshness response to refresh changed rows rather than refetching the whole table.
• Show who else is present, mirroring the presence indicator :feature:documents already has.

Tests: heartbeat lifecycle (starts on open, stops on leave); stale-row refresh.

---

Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

[Adron]

Implemented in #123 (branch issue/53-list-collab-poll). Closing here — review and any follow-up happens on the PR.

A serious pre-existing bug was found and fixed as part of this, and it is worth reading first: RowDto read the cell map from a data key, but the API sends rowData — so every list row's cells decoded as empty and the grid has been rendering "—" for every cell against real data. I verified it independently: rowData appears 12 times in the OpenAPI spec and 4 times in the help-centre lists reference; data appears nowhere as the row field name. The poll could not have worked without fixing it, since there would have been no versions to quote.

A live probe (on a throwaway list, since cleaned up and verified) settled three things the spec left open: changed[] elements are whole rows in the same shape GET …/data returns; deleted is a bare array of id strings; and a stale version returns the row even when collaborative is false, so that flag is advice about polling rather than an access gate. An unclaimed share link does not flip it — it tracks actual watchers/collaborators.

Still unconfirmed: the users[] presence element shape. Establishing it needs a second real person on the list, and the only way to get one would have been emailing a stranger an invite, so it is modelled defensively from the help centre instead.

Known gap worth its own issue: the endpoint only reports rows you asked about, so rows another person inserts are not picked up by the poll — a manual reload is still needed for those.