Developer SSH listener loses projected key during concurrent boot reconciliation #641

Observed during the first controlled boot of signed Mini Plus candidate 0.1.0-dev-55e0664b.

Evidence

• Wi-Fi associated and TCP/22 served the pinned Dropbear host key.
• The server allowed public-key authentication only but rejected the retained automation Ed25519 key before signature.
• Bloom Remote Keys reported the same durable key fingerprint ending b9002791.
• The installed bloom-dev-ssh and bloom-dropbearmulti bytes are identical to the previously working 2933f70 release.
• No second reboot, Wi-Fi mutation, key mutation, host-key bypass, password authentication, or alternate identity was attempted.

Root cause
Boot reconciliation has two SSH lifecycle owners. bloom-network calls the compatibility services path, which starts bloom-dev-ssh in the background, then immediately calls bloom-network-services reconcile, which starts the same helper again. Concurrent starts can race stop_dropbear and prepare_runtime_key. On firmware that needs Bloom's /home bind-mount fallback, the losing starter can unmount /home after the surviving Dropbear is listening. The process remains reachable but its authorized_keys path has disappeared.

Required correction

• Make bloom-network-services the sole SSH/SFTP lifecycle owner.
• Serialize primary bloom-dev-ssh start and stop operations with a bounded, stale-owner-recoverable lock.
• Add a concurrent-reconcile regression test that models exclusive listener ownership.
• Preserve key-only authentication, the sole durable automation key, strict host-key pinning, and the network-transaction shadow listener.
• Revalidate with focused and exhaustive shell tests, affected ARM/package CI, and one controlled signed Mini Plus boot before confirmation.

Hardware status
The candidate remains unconfirmed. Its retained known-good release and pre-update snapshot are intact. Physical display, controls, shutdown behavior, gameplay, and save semantics are not established by this SSH failure evidence.