fix(routing): stamp visited only for frontier-cap survivors (#67)

[DocGerd]

What

The isochrone solver's solve() stamped visited over all byKey ring
winners before the MAX_FRONTIER truncation. A node stamped and then capped
out never expands, yet its visited-stamp permanently prunes every later arrival
into that same prune cell (visitedDominates: stamp no later AND no more
maneuvers). When a sole gateway cell's first arrival is the capped-out one,
the cell is sealed with no surviving subtree, so a still-connected destination is
reported unreachable — routes can be missed under a large frontier. Filed
out-of-scope from PR #66.

Fix

Stamp visited after the cap slice, over the survivors only (recomputing
each survivor's pruneKey). Survivors always expand next ring, so every
domination guarantee is preserved; capped-out nodes no longer seal cells they
never grew a subtree in. When the frontier fits under the cap, the survivor set
equals every byKey winner, so the uncapped path — every real-mask route whose
frontier peaks below MAX_FRONTIER — is byte-identical to before.

MAX_FRONTIER's value (30 000) and the domination rule are unchanged.

Test seam + regression

• New injectable SolveParams.maxFrontier (defaults to MAX_FRONTIER) so a test
  can drive the cap into the truncating regime without a 30 000-node mask.
• isochrone.followups.test.ts — issue Solver: visited stamps written before the MAX_FRONTIER cap can seal prune cells with no surviving subtree #67 block: an H-shaped water region with a
  dead-end decoy gulf pointing straight at the destination and a sole
  through-corridor. Under small caps stamp-before-cap seals the corridor and
  returns unreachable for a provably connected destination
  (mask.cellsConnected — an independent BFS oracle, not the solver); the fix
  returns a valid detour route (all legs navigable; summed length > the blocked
  direct line) at every cap tested [11, 12, 16, 17, 22].
• TDD verified: the test is RED on stamp-before-cap (fails at cap=11,
  no-route vs ok) and GREEN on the fix; the four issue-Solver follow-ups from #20 review: time-aware visited pruning; direct-arrival substeps; capture-hop validation #21 tests are
  unaffected either way.

Verification

• npm --prefix app run typecheck — clean
• npm --prefix app run lint — clean
• isochrone (unit + followups) — 12/12 pass
• realmask.repro.test.ts — 6/6 pass; wall-time 87 s (pre-fix) vs 91 s (fix),
  within run-to-run variance (real routes never hit the cap → the fix is a no-op
  there)
• invariants.property + planRoute + motor + postprocess + viaPoints +
  relaxedDepth — 35/35 pass

Closes #67

[DocGerd]

Self-review (pre-merge) — ran a multi-lens adversarial review of this diff. Verdict: clean, no findings → no review threads to post/resolve.

• Correctness of the reorder: the uncapped path is byte-identical. Every node stored under key k was inserted via byKey.set(pruneKey(child…), child), so the post-truncation pruneKey(n…) recompute equals k; componentwise-minima makes stamp order irrelevant. In the capped regime the fix stamps strictly fewer cells (survivors only) → visitedDominates prunes strictly less → it can only admit more re-arrivals, never wrongly prune. Capped-out stampers have no surviving subtree — exactly the unsound seal being removed.
• Test integrity (repo lesson feat(profile): depth-over-time route profile with wind/heading indicators #50, mutation lens): RED-check executed — restoring stamp-before-cap makes the regression test fail (cap=11: expected 'no-route' to be 'ok'); the fix turns it green. The oracles (mask.cellsConnected/mask.segmentNavigable BFS over the byte grid, haversineNm) are independent of solve(), so the assertion is not a tautology.
• Performance: provably a no-op at the production cap — the real-mask frontier peaks ~15k < MAX_FRONTIER (30k), so the truncation branch never fires; realmask.repro 6/6.
• Conventions: typecheck + lint clean; maxFrontier? is a documented optional seam defaulting via ??, with no test-only surface leaking into production callers (exactOptionalPropertyTypes-safe).

Merging to develop once required checks (app + e2e) are green.

[DocGerd]

Merged into develop: fix commit 677095a landed via merge commit 83e2ecf (Merge pull request #94), which is now the develop tip. GitHub returned a 504 Gateway Timeout during the merge, so the ref updated correctly but the PR merged-flag, branch auto-delete, and the Closes #67 auto-close did not fire. Reconciling manually: closing this PR (the change is already in develop), deleting the branch, and closing #67 with a reference to the merge commit.