Use AST-aware navigation evidence for route reachability

[coderabbitai]

Summary

Replace the raw-text navigation-reference matching used by the route-reachability guard with AST/token-aware extraction, or introduce a shared route manifest that provides equivalent authoritative reachability evidence.

Rationale

tests/route-reachability.test.ts currently scans complete source-file text and uses a navigation-context regex. The narrow matcher is sufficient for the wiring-focused work in #1030, but it can still treat comments, string content, and unrelated object properties as route links while missing valid object-form or computed navigation. The test should derive reachability from actual navigation syntax or a canonical manifest.

Affected area

• tests/route-reachability.test.ts
• Navigation components and route-builder modules as needed for AST extraction or manifest integration

Required changes

1. Replace raw full-file regex scanning in referenceRegExp / isReachable with an AST/token-aware approach, or consume a shared route manifest.
2. Count only genuine navigation uses (for example, Next Link hrefs and supported router/redirect calls).
3. Do not count comments, route-ownership comparisons, ordinary strings, or unrelated object properties as navigation evidence.
4. Recognize supported object-form and computed navigation expressions where their target can be established.
5. Preserve existing canonical builder-target handling and the self-file exclusion behavior.
6. Keep the guard offline and deterministic.

Acceptance criteria

• A comment or unrelated { href: "/route" } object does not make an orphan route reachable.
• Valid supported navigation constructs are recognized, including the documented router/redirect patterns.
• Existing reachability coverage for canonical builders remains intact.
• Focused tests cover false positives and false negatives introduced by the previous raw-text matcher.

Backlinks

• Deferred from PR Add page/button wiring guardrails and fix audited defects #1030: Add page/button wiring guardrails and fix audited defects #1030
• Review discussion: Add page/button wiring guardrails and fix audited defects #1030 (comment)
• Requested by @BigSimmo

[coderabbitai]

🔗 Related PRs

#739 - feat: add PWA shell, redirects, and Playwright readiness fix [merged]
#752 - refactor: centralize search route ownership [open]
#882 - Fix(differentials): route "Compare selected" directly to resolved presentation workflow [open]
#883 - Fix(differentials): route "Compare selected" directly to resolved presentation workflow [open]
#885 - Fix(differentials): route Compare selected to resolved presentation workflow [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Summary of GitHub Issue:

Title: Use AST-aware navigation evidence for route reachability

Overview:
The current route-reachability guard in tests/route-reachability.test.ts relies on raw text and regex operations to determine navigation references, which causes several issues, including false positives and negatives. The proposal is to replace this with an AST (Abstract Syntax Tree) or token-aware approach, or alternatively, integrate a shared route manifest for authoritative evidence.

---

Key Points:

1. Problem:

   • Existing regex-based navigation-reference matching in referenceRegExp and isReachable is flawed.
   • False positives: Comments, string content, and unrelated object properties incorrectly detected as route links.
   • False negatives: Valid object-form or computed navigation expressions might be missed.

2. Proposed Solution:

   • Transition to an AST-aware system to parse and understand actual navigation-related syntax.
   • Alternatively, introduce and consume