Undo and older Homes fetch components by name, so they get the newest release's bytes #287

Found 7 Oct by Anders's real Undo (alpha.8 → alpha.7 with elastos update --rollback-to QmYtcAdb…): the alpha.7 Runtime binary and components.json downloaded and verified, then media-provider failed "Checksum mismatch … Expected a1775b32… (alpha.7), Got 3063acf4… (alpha.8)". The update refused and restored the alpha.8 files, as it should.

Root cause: the binary and components.json are fetched by their signed CID (update.rs ~1472, ~1515), which works. Support components are fetched by release name (setup.rs install_first_party_component_via_carrier; System staging prefers release-path:), and the seed holds only the newest file under each name.

Fix: fetch every component by its signed CID with the same existing content fetch the binary uses; the name is used only when a descriptor has no CID. Every published descriptor has a CID (131 of 131 in alpha.8) and the seed holds all of them. No server change.

Done means

• Terminal and System fetch components by their signed CID; the checksum check is unchanged. (evidence: PR alpha.9 train: Undo fetches components by CID (#287), #279 follow-up, reproducible media tools, #282 #294, Undo and older Homes fetch components by name, so they get the newest release's bytes #287 (comment))
• Test: when the name would give other bytes than the CID, the CID bytes are used (fails before). (evidence: PR alpha.9 train: Undo fetches components by CID (#287), #279 follow-up, reproducible media tools, #282 #294)
• Real proof on alpha.9: Undo 9 → 8 on Mac, Linux x86-64 and Jetson restores alpha.8 and keeps data written after the update. (evidence: Undo and older Homes fetch components by name, so they get the newest release's bytes #287 (comment), Undo and older Homes fetch components by name, so they get the newest release's bytes #287 (comment); Linux was Undo 10→9 with the fix on both sides, UP-07: Accept updates on Mac, Linux and Jetson #113 (comment))

Later, not part of this fix: offline Undo (keeping the replaced files) and a held-only streamed fetch so any host can serve (#281; work on branch fix/287-fetch-by-cid). Part of #89, #109.

Browser plan reconciliation — 2026-10-08

#288 and #217 consume the single content-fetch contract (exact CID plus signed checksum/size, bounded streaming, deterministic refusal of substituted or unavailable bytes) now owned by #281. Image acquisition uses that shared operation. Operator approval is needed for any seed work.