feat: support migration-safe custom lane deployments

[joryirving]

Parent: #381

Goal

Add migration-safe support for custom lane deployments while preserving existing data and current default behavior.

Current problem

Existing installs may already have issues with currentLane values like normal, escalated, and backlog. Configurable lanes must not strand or hide existing issues when configuration changes.

Requirements

• Existing default installs continue to work with no config changes.
• Unknown existing lane values are handled safely.
• Provide a clear compatibility story for changing lane config.
• Support migration from current default lanes to a custom lane set without data loss.
• Support single-lane installs.
• Avoid destructive migrations.

Suggested behavior

When the configured lane set changes:

• Issues with lanes still present in config remain untouched.
• Issues with lanes no longer present should be surfaced clearly.
• Provide a documented migration path to remap old lane IDs to new lane IDs.
• Do not silently drop or hide issues with old lane IDs.

Possible config addition

laneAliases:
  normal: default
  escalated: default

or:

laneMigration:
  normal: local
  escalated: frontier

The exact shape is flexible, but the behavior must be explicit and testable.

Non-goals

• Do not change external workflow repos.
• Do not perform automatic destructive data rewrites.
• Do not require users to use any specific lane names.

Acceptance criteria

• Existing default lane values remain valid under default config.
• A custom config can define aliases/remaps for old lane IDs.
• Unknown/unconfigured lane values are visible in diagnostics or UI rather than silently hidden.
• Single-lane configuration works with existing issue data after documented remap.
• Tests cover default config, custom config, and stale/unknown lane values.

Validation

• npm run lint
• npm run typecheck
• npm run test
• npm run build