[Feature] Add CHAT_PATH_LINKS alias mappings for portable shorthand prefixes

[DerrickBarra]

In Plain English

This adds one more layer of portability to chat path links.

Right now Nerve already knows how to treat workspace/... as a built-in product shorthand for canonical /workspace/... paths. This follow-up would let deployments declare additional shorthand prefixes such as projects/... in CHAT_PATH_LINKS.json, so chat messages can still link to the same canonical workspace targets without hardcoding installation-specific aliases into product logic.

That keeps the product default behavior simple, keeps local shorthand behavior configurable, and gives raw config/editor users parity without introducing a bespoke alias-management UI in this lane.

Problem

The current CHAT_PATH_LINKS.json shape supports configurable prefixes, but it cannot express local shorthand-to-canonical rewrites.

That leaves a gap after the workspace/... follow-up lane:

• built-in workspace/... support is now product behavior and should stay that way
• other shorthand forms like projects/... are deployment-specific and should not be baked into core matching rules
• raw config users need a declarative way to say "when you see projects/..., normalize it to /workspace/projects/... before matching/opening"

Without that alias layer, deployments either lose those shorthand links or have to widen matching in less explicit ways.

Proposed Solution

Extend CHAT_PATH_LINKS.json from a flat prefixes-only config to support both:

{
  "prefixes": ["/workspace/"],
  "aliases": {
    "projects/": "/workspace/projects/"
  }
}

Scope for this lane:

• keep prefixes support intact
• add aliases support for shorthand-prefix rewrites to canonical /workspace/... prefixes
• preserve built-in workspace/... behavior as product behavior rather than moving it into aliases
• apply the same alias-aware behavior anywhere the raw template/editor already exposes CHAT_PATH_LINKS.json
• do not add a bespoke alias UI in this lane; raw template/editor parity is enough

Alternatives Considered

• Hardcode more shorthands like projects/... into product logic
  • rejected because those are installation-specific and not portable product defaults
• Add a dedicated alias-management UI first
  • rejected for this slice because the raw config/editor already provides the needed surface and keeps the lane smaller
• Broaden prefix matching heuristics without explicit aliases
  • rejected because explicit alias mapping is clearer, safer, and easier to reason about

Additional Context

Verified dogfood scope from workhorse-v1:

• CHAT_PATH_LINKS.json supports prefixes plus aliases
• aliases map shorthand prefixes like projects/ to canonical /workspace/... prefixes
• built-in workspace/... behavior remains product behavior
• no bespoke alias UI in this lane; raw template/editor parity only

Fresh validation on the implementation branch passed:

• npm run lint
• npm run build
• npm test -- --run