terminus gaps when a WP was implemented directly on the target branch (sanctioned fallback): merge has no --skip-lanes, accept refuses with un-followable guidance, mission close chokes on an orphaned coordination_branch

## Summary
When a WP is implemented directly on the target branch (a sanctioned fallback), the terminus surfaces (merge / accept / mission close) each fail: `merge` hard-fails on a missing lane branch after already committing acceptance bookkeeping (half-terminated state), `accept` refuses with the same impossible materialize-then-retry guidance as B01, and `mission close` chokes on a `coordination_branch` key whose worktree was removed. Shared root cause: terminus assumes lane branches + a live coordination worktree exist and doesn't model the direct-on-target path.

Related open: #2367 (merge blocked by coordination worktree), #668 (first-class mission-correction workflow), #2618 (unify flatten_mission across doctor --fix vs mission close --discard). Related closed (verify-repros): #1718/#1889/#2250 (coordination_branch declared but no worktree → errors), #2120 (mission close --discard no-ops on coord topology), #2280 (close/merge leave retrospective + event-log append uncommitted).

## Sub-issues

### B08 — terminus gaps x3 for direct-on-target implementation + orphaned coordination_branch
- Symptom (1): `merge` hard-fails "Lane branch kitty/mission--lane-a does not exist" — no `--skip-lanes`/`--no-lanes` to declare "implementation already on target"; it had ALREADY committed acceptance bookkeeping before failing → half-terminated state; manual terminus required. (2): `accept` errors with the protected-branch refusal (`no_op_wrong_surface`) unless the escape hatch is set — but the error gives the impossible materialize-then-retry guidance instead of naming the hatch (same root as B01). (3): `mission close` refuses while `meta.json` has a `coordination_branch` key whose worktree was manually removed; the remedy (remove the key) works but close then prints a DOUBLED slug ("Coordination worktree torn down for -"). Also: `mission close --json` is unsupported (inconsistent with siblings).
- Repro: implement a WP directly on the target branch (no lane); run `merge`, then `accept`, then `mission close` (after manually removing the coord worktree).
- Expected: a `merge --skip-lanes`/`--no-lanes` path (transactional — don't commit bookkeeping before validating lanes); accept names the escape hatch (shared fix with B01); mission close tolerates an orphaned `coordination_branch` cleanly, fixes the doubled-slug string, and supports `--json`.
- Source: `spec-kitty merge` / `accept` / `mission close`.

## Why bundled
One terminus story: the merge→accept→close sequence for a mission whose implementation landed directly on the target branch. The three failures share the "lanes/coord-worktree assumed present" root and are fixed together as a coherent direct-on-target terminus path. Facet (2) shares its fix with B01 (issue 01) — cross-reference at implementation time.

Reported from weekend dogfooding of spec-kitty 3.2.5 (Mission Control multi-mission program), 2026-07-11/12. Filed as a bundle to fix as one governed mission.

Start with the implementations of the `merge`, `accept`, and `mission close` commands, then reproduce the direct-on-target sequence described in the issue, including removal of the coordination worktree. Done means the flow handles missing lanes transactionally, names the accept escape hatch, tolerates an orphaned coordination_branch without the doubled slug, and supports `mission close --json`.

Written by the indexing model from the issue text.