bad-code: decide when to remove legacy law capability API alias

[flyingrobots]

Observed while preparing PR #539.

wesley law capabilities --json now emits the PRD-canonical wesley.law-capabilities/v1, but Holmes intentionally still accepts the pre-canonical wesley.capability-report/v1 alias in crates/wesley-holmes/src/application/law_capability_ingest.rs and normalizes it internally.

That compatibility path is useful while this branch is settling, but it should have an explicit lifecycle before Holmes grows a public CLI or report surface.

Acceptance criteria:

• Decide whether wesley.capability-report/v1 is a temporary compatibility alias or a long-lived accepted input.
• Document the lifecycle in the Holmes README / implementation status docs.
• If temporary, add the release or slice where it can be removed.
• If long-lived, make the alias part of the explicit compatibility contract and keep regression coverage for canonical normalization.

[coderabbitai]

🔗 Related PRs

#504 - Compile runtime optic artifacts [merged]
#534 - Validate strict weslaw bindings [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!