create --type bugfix
Serve registry lost-update: broker Attach/List and brain TTL reaper use different REGISTRY_WRITE mutexes
Found 2026-09-14 by the #304 Windows consumer leg on fix-2 7890ead39bb7f14ed44aaae44b0951f098ffe9ac (parent S2 527cd8e8): spt::webserve_attachment_e2e::an_attachment_is_snapshot_served_fetched_back_and_named_by_its_message red at crates/spt/tests/webserve_attachment_e2e.rs:568 — after two ATTACH calls the `serve list --json` rows carried report.md, report~1.md and beta.md but NOT alpha.md (the FIRST registration), while both ATTACHED URLs were produced and distinct.

RCA (hertz, from source; evidence .spt/preserved/hertz-attachment-NO4JJOEL/rca-source.json): the broker's Attach/List path and the brain's TTL reaper hold DIFFERENT process-local REGISTRY_WRITE mutexes, so the reaper can publish a stale whole-registry snapshot between two registrations and drop the earlier one. Mechanism proven in source; this incident's exact interleaving is inferred. Pre-existing: the cell is 6/6 green on all prior preserved Windows+Linux phase-B legs (49a08a07, S2, full49) and the fix-2 diff does not touch this path. Intermittent; rate being bounded by a 10x cohort on the exact sha.

Not fixture noise: the assertion names both entries (ARM11), so this is a contract loss, not the retired expired-entry count flake. Same defect class as the two-locks-one-resource hazard.

Fix shape (todlando sizing, read-only): one shared registry write guard for Attach/List/reaper, or read-modify-write under a single lock. Ships in whichever milestone the operator rules (stop-and-referred via lia 2026-09-14 ~13:58Z; #304 scope question).