feat(dashboard): add needs-attention status, distinct from testing

[joliverMI]

Summary

• Adds a seventh dashboard status, needs-attention, distinct from testing: testing is done and optional to review (nothing lost if he never looks), needs-attention is genuinely blocking on him (a decision, an answer, a physical action).
• needs-attention gets its own column color, its own always-visible section at the very top of the page (above Favorites), sorts first under --sort status, and carries an optional --reason that renders directly on the card.
• CLI (fm-dashboard.sh status <id> needs-attention --reason "..."), HTTP API (POST /api/tasks/{id}/status), the fleet-dashboard skill, and docs/dashboard.md are all updated together so the status is actually usable end to end.
• The fleet auditor's sweep procedure now checks needs-attention card age as an asymmetric finding: a long-lived needs-attention card is a discrepancy (he wasn't asked clearly, or the ask never reached him); a long-lived testing card is not, by design.
• Existing SQLite databases migrate in place (a nullable column addition via PRAGMA table_info + ALTER TABLE); verified against a copy of the live production dashboard.db (20 existing cards, all intact, no waiting/paused cards currently in play).

Reclassification of existing Testing cards

The brief noted several cards currently in testing may actually belong in needs-attention. I reviewed the full recorded data (prompt + all note tabs) for all 11 cards currently in testing on the live board and found no card carrying an explicit unresolved question, a needs-tab ask, or other recorded signal that it is blocked on the Admiral rather than just built-and-optional-to-review - each reads as a self-contained implementation/bug-fix request.

One soft, uncertain candidate: colour-groups-become-override-layers-h9mk ("Apply the current overrides that I have from back when it made more sense in spot FX") references override values that may only exist in the Admiral's own head/records rather than in the repo - worth checking whether the implementation used his real values or a placeholder. I did not move it; flagging for firstmate's/his judgment rather than guessing.

No cards were moved by this PR - only the mechanism to move them was added. Reclassification (if any) is a live-data change on the running board, not a code change, so it stays out of this diff.

Test plan

• tests/fm-dashboard.test.sh passes locally, including new test_needs_attention_status_carries_reason_and_sorts_first coverage (reason persistence, sort-order-first, reason clears on leaving the status).
• bin/fm-lint.sh clean (shellcheck) on the changed shell files.
• python3 -m py_compile clean on the changed Python files; node --check clean on app.js.
• Migration verified against a copy of the live production dashboard.db - existing rows untouched, new column nullable.