Give the migration's .tmp orphan a home in the operations runbook

[7487]

What

Adds a runbook entry to docs/design/operations.md for the <name>.<hex>.tmp staging file that
migrate_state_root can leave behind, plus a CHANGELOG.md entry under ### Internal.
Prose only — no behaviour change, no code touched.

Why

migrate_state_root stages each entry as <name>.<hex>.tmp beside its destination and renames it
into place. Cleanup is in a finally, so an error or Ctrl-C clears the staging entry; SIGKILL
or power loss between the copy and the rename does not, and leaves one in the operator's state
root. The docstring is explicit that this orphan is deliberately visible — an orphan is the
operator's to delete, and they cannot delete what they cannot see.

Visible only helps if there is somewhere to look it up, and there was not. The only mention was the
0.21.0/0.22.0 repair paragraph in CHANGELOG.md, which is addressed to operators upgrading across
that specific pair of releases — version-scoped history rather than a durable reference. An
operator on 0.23+ who finds usage.jsonl.<hex>.tmp next to their usage log has no reason to read a
changelog entry about versions they never ran, and grep -rn '\.tmp' docs/design/ confirmed
operations.md did not mention the file anywhere.

The new entry is symptom-shaped like its neighbours in that section and stands on its own: what the
file is, when it is left behind, that nothing reads it, and that deleting it is safe. It also says
why nothing sweeps it up later — a sweep over the destination directory is the shared-name
collision again, one directory wider — because "why isn't this cleaned up automatically" is the
next question an operator asks, and leaving it unanswered invites someone to close it as a gap.
No 0.21/0.22 framing, so the entry does not expire.

Scope is the two files the issue names. The issue's fourth acceptance box — republishing the Design
Overview Artifact to its existing URL — is yours: it is not a repository file and a fork cannot
reach that URL. Everything the Artifact would be rebuilt from is in this diff.

Test plan

make test — 791 passed, 17 skipped, ruff and mypy clean (they gate the target). Nothing here is
executable, so that is a no-regression check rather than coverage of the change; the substantive
verification was reading router.py's migrate_state_root and atomic.staging_path against the
prose, so that the entry describes what the code actually does:

• the suffix is f"{path.name}.{uuid.uuid4().hex}.tmp" — no leading dot, hence visible;
• staging is a sibling of the destination, so the orphan lands in the new state root;
• _discard(staged) is in a finally, so only a signal that skips it orphans an entry;
• the migration copies and never deletes, so the legacy original survives deleting the orphan.

Also checked the wording does not contradict the § Concurrency work #196 covers, or the
observability.md § Migrated-log integrity notice above it in the same section.

Fixes #198

🤖 Generated with Claude Code

[Jason-Vaughan]

Thanks for this — and for reading migrate_state_root rather than trusting the changelog. Your
diagnosis is exactly right: the orphan was documented only in a version-scoped repair paragraph,
which is no use to an operator arriving on 0.23+ who has never run 0.21.

Every factual claim in the entry checks out against the code — the staging format, the
destination-sibling placement, the finally, the re-run guard, and that the migration copies and
never deletes. The symptom-shaped heading matches the section's convention and ### Internal is
the right changelog tier.

The audit turned up one thing worth adding, and it is the only change to your entry: "deleting it
is safe" is true of an orphan, but an operator cannot tell an orphan from a staging file a
migration is using right now — the names are identical and every console script migrates on
startup. Deleting a live one makes that run print could not move state from … (the next startup
finishes the move, so nothing is lost). Without that clause the runbook promises an operator
something it cannot deliver, so it is carried in the reconstruction.

Per the Clean Room Reconstruction Standard in CONTRIBUTING.md we merge ideas rather than raw
bytes, so this is open as a reconstruction in
#217 with your name on it — the same way
@be-student's #137 and #144 were handled. You are credited by
@mention in the changelog entry and in the commit message. The Design Overview Artifact republish
you flagged as ours is indeed ours, and it is done; you read that boundary correctly.

Closing this one in favour of #217 — not because anything was wrong with it, but because the
standard means we cannot merge the bytes. Thank you for the contribution.