feat(tickets): separate ticket reading from presentation

[BjRo]

Why

Standalone ticket requests currently conflate loading authoritative issue evidence with presenting the complete issue, which makes read-ticket awkward to compose into larger tasks. Closes #208.

What changed

Split the darrow-tickets-github contract into read-ticket for contextual evidence and show-ticket for verbatim standalone presentation. Update routing, specifications, documentation, manifests to version 0.5.0, and colocated evals while preserving exact-reference, read-only, failure, and shell-safe boundaries.

Verification

• bun run lint — passed.
• bun run lint:ts — passed.
• bun run lint:shell — passed.
• bun run typecheck — passed.
• bun run check:decisions — passed (10 ADRs).
• bun run check:docs — passed (210 Markdown pages, 15 plugins, and both guide entrypoints).
• bun run check:python --package plugins/capability/darrow-tickets-github/backend — passed (154 tests; 100% line and branch coverage).
• Plugin dry eval preparation — all 34 ticket-plugin cases prepared successfully.
• Targeted single-trial native evals for read-ticket compound routing, retrieval failure, shell-sensitive URLs, explicit context loading, incomplete references, and standalone-show exclusion, plus show-ticket direct display, missing tickets, foreign URL pressure, relation failure, and shell-sensitive URLs — passed at 1.0 against the 0.8 threshold on their relevant Codex or Claude harnesses.

Review notes

Behavioral compatibility intentionally changes routing: standalone read, show, fetch, or display requests now select show-ticket, while compound tasks select read-ticket. Review docs/specs/ticket-management.md and the two skill contracts first; the plugin version moves from 0.4.2 to 0.5.0. No additional migration, security, licensing, or follow-up concerns are known.

Checklist

• I have read and followed CONTRIBUTING.md, including the contribution
  licensing terms.
• I added or updated the applicable invariant before implementation, or
  this change does not affect a capability invariant.
• I added or updated colocated evals, or this change does not affect skill
  behavior.
• I confirmed that each changed plugin remains self-contained, or this
  change does not affect plugin content.
• I ran bun run check:python, or this change does not affect registered
  Python packages or their repository quality infrastructure.

[BjRo]

not sure wether that's actually a good idea on second thought

[BjRo]

Closing this approach because the standalone-versus-compound distinction is presentation and continuation policy within one exact-ticket retrieval capability, not a separate capability boundary. Issue #208 now specifies one read-ticket skill: standalone retrieval relays the authoritative stream, compound retrieval returns evidence to the enclosing owner, and retrieval failure blocks only work that depends on that evidence. The branch is being preserved temporarily as a reference while the replacement starts fresh from main.