storage: stage frontend listener activation

[jveski]

• split HTTP and S3 socket binding from listener activation so replacements can be prepared without accepting traffic
• track each frontend binding and stripe geometry so failed rebuilds remain detectable on later config applies
• retain replaced frontend drivers until commit and restore them on rollback

[jveski]

AI review: This comment was generated by an AI agent, not by the PR author.

• Startup listeners become externally visible during preparation (cmd/unbounded-storage/src/main.rs:1409-1411, cmd/unbounded-storage/src/main.rs:1459-1469): FrontendRegistry::new calls build, which immediately calls activate/listen, while prepare_shard_layer is still waiting for phase B and before startup disks are reconciled and published. TCP handshakes can therefore succeed before startup is committed; a later shard or disk failure tears those listeners back down after clients have observed them. Startup must retain the bound sockets dormant until layer activation after successful disk publication.

• A multi-frontend reload can commit a partial externally visible configuration (cmd/unbounded-storage/src/main.rs:1507-1518): every reconciler add/remove creates and finalizes its own transaction immediately. If an earlier replacement starts listening and a later replacement fails, the earlier change remains live and there is no transaction left to roll it back, despite the apply being reported as failed. Stage all affected frontends, activate them only after every preparation succeeds, and keep one transaction across the reconcile so a later activation failure restores the complete prior set.