fix(#2043): reject single-digit slug word in phase-token extraction (all sites)

A phase whose slug's first word is a bare single digit (dir
`46-6-rs-pipeline-orchestrator`, roadmap phase "6 Rs Pipeline Orchestrator" →
slug `6-rs-…`) had its phase token over-collected as `46-6` instead of `46`, so
`gsd-tools` phase-by-number lookups (init.plan-phase, init.phase-op, and
downstream execute/verify/ship) resolved phase_dir=null / has_context=false.

Root cause: an over-broad "looks numeric" test (`/^\d/`, `\d+(?:-\d+)*`)
classified token segments and could not distinguish a legitimate zero-padded
sub-phase segment (`01`, `02`) from a single-digit slug word (`6`). Zero-padded
phase/sub-phase segments are always ≥2 digits, so requiring ≥2 digits is the
structural distinguisher. Applied consistently across every same-class
implementation the triage identified (fixing extractPhaseToken alone leaves the
health-check and milestone-filter subsystems exposed):

- src/phase-id.cts extractPhaseToken — a pure-numeric leading segment continues
  only with ≥2-digit segments; a letter-prefixed milestone id (`M1`) still
  admits its single-digit sub-phase (`M1-2`).
- src/validate.cts PHASE_TOKEN_FROM_DIR_RE (W005/W006/W007 health checks) and
  canonicalPlanStem (I001 plan/summary pairing).
- src/roadmap-parser.cts isDirInMilestone numericRe (getMilestonePhaseFilter —
  highest blast radius: a false negative silently excludes a phase from the
  milestone).
- src/core-utils.cts + its verbatim duplicate src/phase.cts extractCanonicalPlanId.

Regression tests added across tests/{phase-id,health-validation,core-utils,
roadmap-parser}.test.cjs using the shared `46-6-rs-…` fixture, asserting the
token resolves to `46` (not `46-6`) while legit multi-segment tokens
(`01-02`, `02-03-04`, `M1-2`, `68-01`, `02-01`) are unchanged. The
roadmap-parser test exercises the real getMilestonePhaseFilter end-to-end.

The residual ≥2-digit-leading-slug case (e.g. `NN-2024-roadmap`) stays out of
scope — subsumed by the #612 / #565 phase-ID convention work, per the issue.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

tests/roadmap-parser.test.cjs

@@ -428,6 +428,34 @@ describe('roadmap-parser: getMilestonePhaseFilter', () => {
     assert.strictEqual(filter('02-03-other'), false, '02-03 not in milestone');
   });
 
+  test('single-digit slug word after a phase number is not wrongly excluded (#2043)', () => {
+    // The roadmap uses milestone-prefixed hyphenated phase IDs (e.g. "2-01"),
+    // which switches getMilestonePhaseFilter's dir-matching regex into
+    // hyphenated mode. Phase 46's roadmap name "6 Rs Pipeline Orchestrator"
+    // slugifies to a dir starting with a single-digit word ("46-6-rs-…").
+    // Before #2043, the hyphenated-mode regex over-collected that single
+    // digit into the phase token ("46-6"), which never matched the roadmap's
+    // "46" phase number, so the dir was wrongly excluded from the milestone.
+    writeState(tmpDir, { milestone: 'v1.0' });
+    writeRoadmap(tmpDir, [
+      '## v1.0: Current',
+      '### Phase 2-01: Alpha',
+      '**Goal:** first alpha phase',
+      '',
+      '### Phase 46: 6 Rs Pipeline Orchestrator',
+      '**Goal:** orchestrate the rs',
+    ].join('\n'));
+
+    const filter = getMilestonePhaseFilter(tmpDir);
+    assert.strictEqual(
+      filter('46-6-rs-pipeline-orchestrator'),
+      true,
+      '46-6-rs-pipeline-orchestrator (phase 46, single-digit slug word "6") must match Phase 46',
+    );
+    // Legit milestone-prefixed dir still matches as before.
+    assert.strictEqual(filter('02-01-alpha'), true, '02-01-alpha matches Phase 2-01');
+  });
+
   test('versionOverride uses specified version slice', () => {
     writeRoadmap(tmpDir, [
       '## v1.0: Old',