Runtime snapshots report storage *capability* but not the resolved effective engine — UI badge reads as "running queue storage"

## Problem

The per-instance badge in the admin UI renders `runtime_instances.storage_capability`, and the reporter (`RuntimeReporterState::storage_capability`, `awa-worker/src/client.rs`) returns `queue_storage` for any queue-storage-**capable** runtime — including one whose effective storage resolved to **canonical** on a canonical-state cluster (every default-built 0.6 worker is capable). Operators reasonably read the badge as "this instance is executing on queue storage", which it does not mean. During a production incident this misread the cluster's engine entirely; the actual engine had to be confirmed from `awa.storage_transition_state`.

The resolved effective engine is known at startup (`resolve_effective_storage`) and logged, but never published in runtime snapshots — the UI cannot show it even if it wanted to.

## Status

The UI half shipped in 0.6.1 (#390): the runtime page derives and shows the effective engine (capability + transition role + cluster routing state) and the sidebar chip labels the cluster from `/api/storage`. **Remaining scope here: publish the resolved engine in runtime snapshots so no client has to derive it.**

## Proposal

- Add `effective_engine` (`canonical` | `queue_storage`) to the runtime snapshot / `runtime_instances`, set from the resolved `RuntimeStorage` (additive column + reporter field).
- UI: show the effective engine as the primary per-instance fact; keep capability as secondary detail ("executing: canonical · capable: queue storage"), and rename the badge accordingly.
- `awa health` / `awa doctor` (#373) fleet views should use the same field.

## Context

Surfaced while diagnosing #388: the cluster-level truth is
`SELECT state, current_engine, details, finalized_at FROM awa.storage_transition_state`
(with `details.auto_finalized = true` marking the silent fresh-install promotion). Related: the auto-finalize promotion itself is only visible as an `info` startup log plus that details flag — worth a louder, durable operator signal when the one-way door is crossed automatically.

Start in awa-worker/src/client.rs at RuntimeReporterState::storage_capability, then trace resolve_effective_storage and the runtime snapshot/runtime_instances schema. Publish the resolved RuntimeStorage as effective_engine, and check the admin UI plus awa health and awa doctor consumers. Done means snapshots expose the effective engine without clients deriving it, while capability remains available as secondary information.

Written by the indexing model from the issue text.