refactor(aidd-orchestrator): make the delivery loop a contract-compliant router

Start with the root router, the routing reference, and the public skill entry point 00-async-dev; trace how route, setup, run, and review currently select and load actions. Compare the shortest and longest paths before and after, preserving provider discovery, trigger aliases, and observable outcomes. Done means the root contains only the contract flow, action table, and transversal rules, with line counts recorded in the PR.

Need

The delivery loop configures unattended delivery, routes one ready work request to delivery, and iterates on review feedback. Its current public name, async-dev, describes an implementation style rather than that outcome.

The public skill remains 00-async-dev in this refactor. Renaming its identifier is a separate compatibility migration; this issue only makes its router understandable, lazy-loaded, and contract-compliant.

Current state

The SDLC provider is already discovered at runtime by capability description. The remaining problem is structural: the always-loaded router duplicates the routing protocol and expands every setup, run, and review detail, although one invocation uses only one path.

Scope

• Make the root router express only route → setup | run | review, its action table, and transversal rules.
• Add internal load boundaries:
  • route resolves the mode from the routing protocol.
  • setup, run, and review each load their existing ordered action sequence only after selection.
• Keep detailed selection precedence, trigger aliases, and conflict handling in the routing reference, with one source of truth.
• Preserve the existing dynamic SDLC-provider discovery and all current setup, run, and review behavior.
• Measure the lines read on the shortest and longest paths before and after.

Out of scope

• Renaming 00-async-dev, changing its invocation, or breaking trigger compatibility.
• Splitting setup, run, and review into separate public skills.
• Changing automation policy, GitHub integration, or the SDLC capability contract.

Acceptance criteria

• The root router satisfies the skill contract: flow, action table, and transversal rules only.
• A mode is selected through one routing source of truth, then only its internal sequence is loaded.
• Setup, run, and review produce the same observable outcomes as before for the same inputs.
• Provider discovery remains runtime-based; no provider name appears in root routing logic.
• Existing trigger aliases continue to select the same mode.
• The PR states shortest- and longest-path line counts before and after.