Town: client cells from their latest run; the backlog after a fresh village

decePub's e2e runs append to out/client.jsonl. The report kept the newest row per test and account, and the backlog
every row, so a failure from a run that picked other accounts stayed in both after later runs passed. Each client
cell now counts as its latest run left it (check.latest_client: the rows within an hour of its newest).

The backlog comes from a fresh village on today's build: 2556 checks pass and 4 fail, three of them peer-to-peer
counts, and one GoToSocial losing a status from its cache (an Update handled as a Create; a restart heals it),
recorded in INTEROP.md rather than as a gap, which would hide our own edits failing there. The community vote and the
Lemmy thread that failed before were data from older builds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw

docs/INTEROP.md

@@ -214,6 +214,10 @@ Findings:
   - `likes`/`shares`;
   - attachment `width`/`height`.
 - **Deleted statuses:** 0.22 keeps a stub and answers 410.
+- **It can lose a status from its cache** (seen once, town 2026-10-05): it looks an Update's object up by URI, and when
+  that fails it handles the Update as a Create, which changes nothing for a status it already has. One followers-only
+  post kept its first text through three Updates, each logged as `activityType=Create`, though its row was there; after
+  a restart the same Update applied. Fresh posts, liked or not, were edited at once.
 
 **Expects**
 - **Signed requests:** every GET and POST is signed, draft-cavage only, with RSA keys. **No RFC 9421 in either