tech-debt: normalize per-service fetch dispatch in refresh.rs

[Bccorb]

Follow-up carved out of #29. That issue covered the row-action dispatch (describe/open/CLI/item count), which is where the SQS d/o gap lived. The fetch dispatch was left alone deliberately, because it is different in kind and normalizing it is its own piece of work.

Problem

Adding a service still means hand-editing several parallel blocks on the fetch side:

• src/app/refresh.rs stream_refresh - exhaustive match over all 16 views, each arm sending a phase label, calling aws::<svc>::fetch_*, and sending the matching RefreshUpdate
• src/app/refresh.rs required_inventories - exhaustive match to &'static [InventoryKind]
• src/app/refresh.rs apply_refresh_update - exhaustive match over RefreshUpdate, writing to the matching App field
• src/app/mod.rs clear_service_data - hand-listed reset of 14 vecs and 11 statuses
• Parallel enums that must stay in sync: InventoryKind, RefreshUpdate

These are exhaustive rather than catch-all, so the compiler does catch a missing arm. That makes this lower risk than #29 was: the failure mode is friction when adding a service, not a silent capability gap.

Why it was not folded into #29

Three things make this resist the same treatment:

1. Three different fetch return shapes. (Vec, ServiceStatus), (Summary, Vec) where status lives inside the summary, and a bare Vec for ECS. clear_service_data already special-cases rds_summary.status, secrets_summary.status, and cloudwatch_summary.status because of this.
2. Composite views. The Findings and CostSavings arms fan out over tokio::join! of many per-service fetches rather than mapping to one fetch.
3. Flat per-service state on App. Two fields per service, with the three shape families above meaning they are not uniformly shaped.

Any registry here has to normalize the return shapes first, which is the bulk of the work and is a behavior-touching change rather than a mechanical one.

Proposed fix

Normalize the fetch return shapes to one form, then drive fetch, inventory requirements, update application, and clearing from a single registration point, alongside the SERVICES registry added in #29.

Acceptance

• Fetch return shapes are uniform across services
• Adding a service touches one registration point on the fetch side
• clear_service_data derives from the registry rather than a hand-written list