host: the diagnostics report names the team file but never its backups #2434

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.
Written-by: FlyBot Dev-1
Claimed-by: FlyBot Dev-1
Claim-Id: fae1ae52c4d94e82a169993f95189468
Branch: dev/1-state-backups
Base: 16d1645

What a person sees

The diagnostics report names the team file — state file: ~/state.json (517 bytes, last written …) — and then says nothing about the backups the store writes beside it. When the team file is the thing that broke, this report is the bundle a person reads to decide whether an earlier copy is still there; the two backups the store actually leaves are state.json.v1 (the one-time version-1 migration backup, core/src/host/store.js:123-143) and state.json.broken-<stamp> (the copy written when the team file could not be read, core/src/host/store.js:199). Neither appears anywhere in the report.

Expected

One line in the same block, right after the team file line:

• state backups: none
• state backups: state.json.v1 (12 KB, 2 h ago)
• state backups: state.json.v1 (unreadable: EACCES)
• state backups: state.json.broken-1762345678901 (12 KB, 1 h ago), state.json.broken-1762345678900 (11 KB, 2 h ago), and 2 more

.broken-<stamp> copies are listed newest first, three at most, and the rest are counted as and k more. Only lstat for each name and one readdir(home) filtered by the exact prefix state.json.broken-; no backup is opened or read — a backup holds the same members, messages and saved keys as the team file, and this report is written to be pasted into a public issue. unreadable: <code> appears only when lstat itself fails: a directory or a dangling link is drawn from its own name, size and age like any other name lstat answers for.

Scope

• core/src/host/diagnostics.js plus the tests for this line.
• The rest of the report is untouched: the state file: line, journal file: and the Read-only row keep their exact wording, and the new line is the only line added.
• Not core/client.js, not patches/ds-bot/0008.

Red first

On the clean base, with only the new cases added: # tests 62 # pass 57 # fail 5 — the five new cases fail because no state backups: line exists. With the fix: 62/62, fail 0. The readable-backup case also compares the rest of the report before and after and asserts that the backups line is the only line that moved.

Duplicate check

GitHub open issues: state backups 0, backups diagnostics 0, state.json.v1 0 (only the closed #1982, a Windows test note). Code: diagnostics.js references neither backup family before this change.