SystemDescription: replace the two Nexus-zone sets with a per-zone lifecycle map

SystemDescription tracks Nexus lifecycle as two sets, active_nexus_zones and not_yet_nexus_zones (projections of the db_metadata_nexus table, added for reconfigurator's upgrade-handoff logic). RFD 726 proposes replacing them with a single map:

nexus_states: BTreeMap<OmicronZoneUuid, NexusZoneState>

/// `nexus-db-model`'s `DbMetadataNexusState` plus an explicit `Expunged`
/// (production represents expungement by deleting the record).
pub enum NexusZoneState {
    Active,
    NotYet,
    Quiesced,
    Expunged,
}

The map matches the table's shape (one row per Nexus, one state), so "both active and not yet" — which the two sets can currently express — becomes unrepresentable. to_planning_input_builder() projects the map back into the two sets PlanningInput carries (Quiesced and Expunged land in neither, matching the production loader), so nothing changes for existing consumers.

The FM simulator needs this to join simulated sagas against Nexus lifecycle (the saga engine's orphaned-saga condition) and to drive its nexus set-state command.

Note, the nexus_states map could, in principle, have a few other readers in the simulator beyond this saga join. In the MVP for the simulator, we propose using a single dummy UUID for things like "which Nexus ingested this ereport" and "which Nexus created this sitrep." We could instead source valid UUIDs from the set of Nexus instances that are currently active, if that were ever useful.

Start in nexus/reconfigurator/planning/src/system.rs at SystemDescription and the active_nexus_zones and not_yet_nexus_zones fields. Trace to_planning_input_builder() and the PlanningInput consumers, then inspect the simulator's saga join and nexus set-state command paths. Done means lifecycle is represented by one nexus_states map while existing consumers still receive the expected projections.