fix(verification): keep passed uat results across verifier re-runs

A phase whose human UAT passed could loop forever between execute-phase
and verify-work. A gap-closure plan, or a later phase editing a covered
file, made the report stale; verify-work only recorded a passed UAT
against human_needed; the re-run verifier could not see the UAT file and
re-emitted human_needed; and execute-phase's human_needed branch then
rewrote *-UAT.md with every row back to [pending].

- verification.uat-evidence: recorded UAT rows plus the covered
  implementation files changed since the UAT. The verifier (Step 8b)
  treats a row that passed on unchanged code as verified and re-lists
  only affected rows, each with a retest_reason.
- verification.seed-uat: merges the report's human items into *-UAT.md.
  Existing rows are kept byte-for-byte; a pass is reset only with a
  recorded reason.
- verification.canonicalize-uat: the single human_needed -> passed flip,
  gated on the uat-only row predicate; refuses a stale report.
- verification.status reports stale_reason; init.progress lists every
  executed-but-stale phase in reverify_phases.
- verify-work and progress re-run the verifier themselves for a stale
  report instead of routing to execute-phase; execute-phase records a
  gap-closure checkpoint's UAT answers before dispatching the verifier.

Fail-closed properties are unchanged: a malformed fingerprint and a real
change to covered code still read stale.

Emitted-Drift-Ack-Growth: execute-phase.md — verify_phase_goal gains the gap-closure uat-record pointer and the merge-not-overwrite human_needed branch; the uat template it replaced moved into verification.seed-uat
Emitted-Drift-Ack-Growth: msd-verifier.md — new step 8b pointer to the lazily loaded verifier-uat-evidence reference plus the human_verified frontmatter key
Emitted-Drift-Ack-Growth: progress.md — route v.stale now re-verifies every stale executed phase in place instead of naming one command

src/init.cts

@@ -272,6 +272,12 @@ interface PhaseCompletionProjection {
    * complete) or ran to completion.
    */
   verification_stale_check_indeterminate: boolean;
+  /**
+   * WHY the report reads `stale` (`readVerificationStatus`'s `stale_reason`),
+   * '' for every other status. Lets progress tell a gap-closure plan the
+   * report never saw from a covered file drifting under a finished phase.
+   */
+  verification_stale_reason: string;
 }
 
 
@@ -330,6 +336,7 @@ function buildPhaseCompletionProjection(
     // internal staleness check could not run to completion.
     verification_stale_check_indeterminate: 'staleCheckIndeterminate' in verificationStatus
       && verificationStatus.staleCheckIndeterminate === true,
+    verification_stale_reason: verificationStatus.stale_reason ?? '',
   };
 }
 
@@ -3872,6 +3879,17 @@ function cmdInitProgress(cwd: string, raw: boolean, options: Record<string, unkn
     phases,
     phase_count: phases.length,
     completed_count: phases.filter((p) => p['status'] === 'complete').length,
+    // Every phase whose plans are all summarized and whose ONLY open item is a
+    // stale report — one verifier re-run each, no plan executes. Progress
+    // offers these as a single "re-verify" action instead of walking the user
+    // back through them one execute-phase route per session.
+    reverify_phases: phases
+      .filter((p) => p['implementation_complete'] === true && p['verification_status'] === 'stale')
+      .map((p) => ({
+        number: p['number'],
+        directory: p['directory'],
+        stale_reason: p['verification_stale_reason'],
+      })),
     in_progress_count: phases.filter((p) =>
       ['executed', 'in_progress'].includes(p['status'] as string),
     ).length,