storage: transact backend, frontend, and disk reloads

[jveski]

• transact shard config reloads with coordinated prepare, commit, and abort
• stage backend, frontend, and disk changes before publishing them to live registries
• defer irrevocable fabric and route updates until abortable preparation succeeds
• bound shard startup and cleanup coordination and fail stop on indeterminate apply state
• reject restart-only backend geometry and open-time disk changes without disrupting live resources

[jveski]

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

• Critical - failed disk transactions can destructively modify disks that are then reported as rolled back. DiskRegistry::reconcile opens every new disk as staging and, if any later open fails, closes the successfully opened staged entries and returns without publishing them (cmd/unbounded-storage/src/storage/disks/mod.rs:178-207). In production, however, UringDiskTarget::open is not a reversible probe: for file disks it runs provision_file before readiness (cmd/unbounded-storage/src/storage/disks/uring.rs:127-143), whose ftruncate can shrink an existing file (cmd/unbounded-storage/src/storage/blockdev/uring.rs:141-184), and engine open with force_format writes a fresh empty tree (cmd/unbounded-storage/src/storage/btree/mod.rs:212-233). Thus an apply containing a valid existing file disk (or force_format disk) followed by any failing disk can truncate/format the first disk, abort the shard transaction, keep the old controller snapshot, and claim rollback even though on-disk data was irreversibly lost. Make the pre-commit stage non-destructive, or classify/execute these opens only after the fail-stop boundary so any subsequent failure terminates rather than returning as rollback-safe; add a production-path regression covering a destructive staged open followed by another disk failing.