fr-dispatchlisted

# fr-dispatch Wraps the `fr apply` CLI. The single command renders the plan, observes GitHub state, diffs, and emits the mutations needed to bring GitHub in line with the plan. Works for first-time creation, incremental updates, and ongoing reconciliation — there's no separate "first dispatch" verb in v2. ## v3: tracking vs queue Plain `fr apply` is TRACKING-ONLY (attribute labels, no queue lifecycle). Queueing is explicit: `fr apply <dir> --to vk --yes` adds `fr:ready` + `runner:vk`, validates the runner against the `fr.runners` registry, and enforces the reachability gate (remote runners pull the repo; tracking-only applies never pay it). The runner choice lives ON THE ISSUE as labels — never in plan files. `fr undispatch` dequeues; per-phase mixing is legal. ## Pre-flight (mandatory) 1. **Audit first, with the read-only verb:** `fr status <plan-dir>` — safely allowlistable, never mutates. Read the header line (created date + age, tick counts, dispatch state) and the per-phase table. A locally-complete plan shows "would refuse create"; if the plan is genuinely done, run `fr archive <plan-dir>` instead of dispatching. Spec rows Unreachable for plans that exist locally = stale refs — `fr repair --yes` normalizes them (File cells are bare slugs as of the 2026-06-06 spec-path-repair design). 2. **Never-dispatched plan? Search the target repo for evidence the work already landed** (the stoa incident: 0/59 steps ticked, but 15 merged PRs and the de