feat(lists): collaborative freshness poll + presence — and a fix for blank grid cells (#53)

[Adron]

Closes #53. Part of epic #49.

⚠️ Read this first: a serious pre-existing bug, found and fixed here

RowDto read the cell map from a data key, but the API sends rowData. So every list row's
cells decoded as empty — the grid has been rendering "—" for every cell against real data.

I verified this independently of the agent that found it: 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. RowDto now reads rowData ?: data and carries version; ListRow gained
version: Int? = null. Existing data-shaped tests still pass unchanged.

This is adjacent to #53 rather than inside it, but the poll could not have worked without it — there
would have been no versions to quote.

The heartbeat

• Tied to the screen's lifecycle. DisposableEffect(Unit) { start(); onDispose { stop() } }, plus
  an isOnScreen flag so a late callback (a row save completing after the user navigated away)
  cannot revive the loop, plus onCleared(). Presence is cleared on stop, so a returning screen
  never shows who was here.
• Surgical refresh, not a refetch. Each beat sends rowVersions for the rows in state plus
  focusedRowId; changed replaces exactly those rows and deleted removes them.
  getListDetail/getRows is never called from the poll path — asserted with a call counter.
• Presence mirrors the documents editor's avatar cluster (same 28dp circles, −8dp overlap, +N
  overflow, nothing when empty) as a deliberate copy — no dependency on :feature:documents.
• Back-off: 10s while a beat brings news, 60s when it brings none or fails, stop after 10 quiet
  minutes (any interaction revives it), and stop outright on collaborative: false — and stay
  stopped in that case. This mirrors the first-party grid's own policy documented in
  helpapi/lists.txt, which warns the backing database bills for being awake and does not autosuspend
  while anything polls. Requests are capped at the documented 500-row ceiling.

Live probe: what it established, and the cleanup

Created a list tmp-53-freshness-probe, one row, and one collaborator share link; then revoked
the link, deleted the row, and deleted the list. (I independently re-verified: the account is back
to its single pre-existing list, "New list", which was never touched.)

Previously unobservable, now confirmed:

• changed[] elements are whole rows in the same shape GET …/data returns —
  { id, rowData, version, createdAt, updatedAt, createdByUser{id,username,displayName,avatar}, lastEditedByUser{…} }. Note rowData, and user objects keyed id, not userId.
• deleted is a bare array of id strings (an unresolvable id comes back verbatim).
• A stale version returns the row even when collaborative is false — so the flag is advice about
  polling, not an access gate.
• An unclaimed share link does not flip collaborative — it stayed false. The flag tracks
  actual watchers/collaborators, not link existence.

Still unconfirmed: the users[] element shape. Establishing it needs a second real person on the
list, and the only route to that would have been emailing a stranger an invite. It is modelled from
the help centre (userId, name, username, color, focusedRowId) and decodes tolerantly for
id/displayName; a nameless entry falls back to username then id, and an entry with no resolvable
id is dropped rather than drawn as a blank avatar.

Verification

./gradlew :app:assembleDebug testDebugUnitTest → BUILD SUCCESSFUL, 1440 tests, 0 failures
(:feature:lists is 268). 14 heartbeat cases, 6 repository, 3 presence, plus mapper additions.
Compose presence tests compile, not executed (no emulator).

Follow-ups

• The endpoint only reports rows you asked about, so rows another person inserts are not picked
  up. A changed row we were not holding is appended defensively, but insertions are not in
  changed. A manual reload is still needed — worth its own issue if it matters.
• Row writes still use the whole-row { data } form; If-Match + { changes, expect } per-field
  deltas and 409 version_conflict handling are untouched. version is now plumbed through, which
  is the prerequisite.
• If the server ever stops returning version, the poll degrades to presence-only rather than
  spamming the whole table. Deliberate.