fix: finish progressive Target detection

.scratch/tui-redesign/issues/03-progressive-startup-and-refresh.md

@@ -4,16 +4,20 @@
 
 **Blocked by:** 02 — Deliver the Operations Console dashboard.
 
-**Status:** ready-for-agent
+**Status:** resolved
 
-- [ ] Interactive application construction exposes Target identity and descriptions before availability and inspection complete.
-- [ ] Startup renders every known Target in a structured Checking state without waiting for aggregate detection.
-- [ ] Availability and inspection results stream to the TUI one Target at a time.
-- [ ] Refresh uses the same progressive behavior rather than a separate aggregate-only path.
-- [ ] Checking rows display a non-color-only progress cue and update independently on success or failure.
-- [ ] Independent completion order does not reorder Targets or move selection to a different identity.
-- [ ] A Target detection failure is represented truthfully without preventing unrelated Target results from appearing.
-- [ ] The progressive Application Interface contains presentation-independent phases and results rather than Bubble Tea types or strings that callers must parse.
-- [ ] Existing non-interactive maintenance behavior remains compatible.
-- [ ] Application tests cover independent completion order, mixed success/failure, and final snapshots.
-- [ ] Complete-Model tests prove the first useful frame precedes detection completion and each subsequent result updates only the relevant row.
+- [x] Interactive application construction exposes Target identity and descriptions before availability and inspection complete.
+- [x] Startup renders every known Target in a structured Checking state without waiting for aggregate detection.
+- [x] Availability and inspection results stream to the TUI one Target at a time.
+- [x] Refresh uses the same progressive behavior rather than a separate aggregate-only path.
+- [x] Checking rows display a non-color-only progress cue and update independently on success or failure.
+- [x] Independent completion order does not reorder Targets or move selection to a different identity.
+- [x] A Target detection failure is represented truthfully without preventing unrelated Target results from appearing.
+- [x] The progressive Application Interface contains presentation-independent phases and results rather than Bubble Tea types or strings that callers must parse.
+- [x] Existing non-interactive maintenance behavior remains compatible.
+- [x] Application tests cover independent completion order, mixed success/failure, and final snapshots.
+- [x] Complete-Model tests prove the first useful frame precedes detection completion and each subsequent result updates only the relevant row.
+
+## Answer
+
+Progressive startup and refresh now publish authoritative Application snapshots per Target while generation checks discard stale overlapping results. Application state and snapshots share one lock, dispatch invalidates in-flight detection before committing mutations, and the dashboard retains selected Target identity—including a newly unavailable selected Target. Adapter detection failures are classified truthfully without changing maintenance inspection semantics.