Lists: the freshness poll does not pick up rows another person inserts #124

Follow-up from #53 (PR #123), which built the collaborative freshness poll.

The gap

POST /api/lists/{id}/data/versions is a version-diff endpoint: the client sends rowVersions
for the rows it is holding, and the server answers with changed (those rows, if stale) and
deleted.

By construction it can only report on rows the client already knows about. A row that another
collaborator inserts has no version for us to quote, so it never appears in changed and the
grid does not learn about it. #123 appends defensively if a changed row arrives that we were not
holding, but insertions do not arrive at all.

Effect: two people editing the same list see each other's edits and deletions live, but not
each other's new rows, until someone pulls to refresh.

Options

1. Client-side: have the poll periodically (much less often than the 10s beat — say every Nth
   quiet beat) re-read GET /api/lists/{id}/data page 1 and merge in unseen ids. Cheap to build,
   but it is exactly the whole-table refetch the versions endpoint exists to avoid.
2. Server-side (better): have the versions response include an inserted[] array, or a list-level
   row-count/high-water mark the client can compare against cheaply. Worth asking the owner whether
   the first-party web grid has this problem too, or whether it solves it some other way.

Option 2 is the right fix if the endpoint can grow it; option 1 is the fallback.

Context

version is now plumbed through RowDto/ListRow by #123, which is also the prerequisite for the
other half of collaborative editing — If-Match + { changes, expect } per-field deltas and
409 version_conflict handling — which remains unimplemented.