feat: make issue reconciliation use configurable lanes

[joryirving]

Parent: #381

Goal

Make issue reconciliation and lane classification config-aware so Dispatch never writes a lane that is not configured.

Current problem

Issue reconciliation/classification currently assumes a small fixed lane set. With configurable lanes, reconciliation needs a generic way to select a lane from the configured claimable lanes or send work to a non-claimable backlog/intake lane.

Requirements

• Reconciliation must use configured lanes from the lane helper/config.
• New or updated issues must not be assigned to unknown lane IDs.
• Preserve existing default behavior when the default lane config is active.
• Keep non-claimable backlog behavior compatible.
• Classification must support at least:
  • default claimable lane fallback
  • escalation/high-complexity lane when the default config has one
  • backlog/non-claimable lane for not-ready issues
• The classifier should not require model calls in the normal sync path.
• Any heuristic mapping should be data-driven or isolated behind helper functions.

Suggested behavior

When using default config:

• concrete/actionable -> normal
• audit/design/high-complexity signals -> escalated
• not-ready/backlog signals -> backlog

When using a single claimable lane plus backlog:

• concrete/actionable -> that single claimable lane
• high-complexity signals -> that same claimable lane unless config explicitly defines a preferred high-complexity lane
• not-ready/backlog signals -> backlog

When using multiple claimable lanes:

• use config metadata or helper logic to identify the default lane and optional high-complexity lane
• never hardcode only two possible claimable lanes

Non-goals

• Do not edit external workflow repos.
• Do not introduce model/provider-specific assumptions.
• Do not remove lane filtering from queues.
• Do not add LLM calls to sync/reconcile.

Acceptance criteria

• Default lane classification remains backward-compatible.
• Reconciliation rejects or avoids writing unknown lane IDs.
• A single claimable lane config can classify actionable issues.
• A multi-lane config can classify to more than two claimable lanes if configured.
• Backlog/not-ready issues still go to a non-claimable lane.
• Tests cover default config, single claimable lane config, and custom multi-lane config.

Validation

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