SystemDescription: fault-injection knobs and hardware lifecycle for the FM simulator

RFD 726 proposes deriving the FM simulator's inventory and in-service-disk inputs from SystemDescription. If we go that direction, we'll need a few additions.

Per-disk setters. None exist today; the only write to a disk's policy is the bulk one in sled_expunge.

• serial_to_disk_id: disk counterpart of the existing serial_to_sled_id
• disk_set_zpool_health: collections currently always report ZpoolHealth::Online
• disk_set_zpool_size
• disk_set_firmware: the NVMe firmware metadata reported in inventory
• disk_set_policy: each SledDisk already stores a PhysicalDiskPolicy; there's just no per-disk setter
• disk_set_inventory_visibility: per-disk analogue of the existing sled_set_inventory_visibility

Caller-supplied serials. Sled serials are hardcoded as serial{N} and a synthetic disk's serial is derived from its zpool's UUID, which no simulator script could predict. Both need to accept caller-chosen values.

Hardware joining and leaving a live system. Disks exist only at sled
creation (via SledBuilder::npools), and sled_remove erases the sled entirely. The simulator needs hardware that is out of the rack (created but not yet inserted, or removed) to stay in the SystemDescription, keeping its serial, settings, and policy while absent from collections.

Read RFD 726 and the SystemDescription implementation in nexus/reconfigurator/planning/src/system.rs, especially the referenced sled and disk builders and lifecycle methods. Trace how serials, disk policies, inventory visibility, and collections are represented before deciding how the simulator can retain hardware outside the rack. Done means the requested per-disk controls, caller-supplied serials, and join/leave lifecycle are supported while preserving hardware state.