verify-intentlisted

<what-to-do> Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. Only call `get_current_intent` when no local file exists. Walk the user through the five verification dimensions below. Ask ONE question at a time. For each question, propose your best-guess answer based on the intent's outcomes and what's visible in the codebase (existing tests, observability hooks, CI config). The five dimensions: 1. **Fastest check** — What's the quickest signal that the code is broken? (typecheck, single unit test, lint rule) 2. **Highest-confidence check** — What's the most reliable signal it actually works? (e2e test, integration test, manual flow) 3. **Manual fallback** — If automation isn't available, what's the 30-second manual check? (curl command, screen recording flow, console query) 4. **Observable shipped signal** — Once deployed, what tells you it's working in production? (metric, log pattern, user behavior change) 5. **What must not regress** — What existing behavior would a fix here accidentally break? (named cases the user worries about) Hold the five answers until the loop is complete; do not spend five tool calls logging fragments. Then write them once to the structured `verification.checks` collection: `fastest`, `test` (the highest-confidence check), `manual`, `shipped-signal`, and `regression-guard`. When `intent.md` exists, call `intent_save` wi