Define a provider-neutral ticket capability boundary for Artificer

[BjRo]

Motivation

The Local Artificer testing experience creates uncertainty about whether GitHub is hardcoded into the automation layer. Darrow already treats ticket systems as independently adoptable capabilities, such as darrow-tickets-github. Users who replace that capability with another ticket system would expect Artificer to obtain ticket polling and related admission behavior through a compatible ticket capability rather than a GitHub-specific core path.

Acceptance criteria

• Artificer's boundary with ticket providers is explicit and documented.
• Ticket polling and the ticket interactions needed for admission use a compatible ticket capability rather than requiring GitHub-specific behavior in the automation core.
• The existing GitHub-backed behavior remains available through the GitHub ticket capability.
• An unavailable or incompatible ticket capability produces a clear blocked result rather than an implicit GitHub fallback.

Open questions

• Which current Artificer ticket interactions are hardcoded to GitHub?
• What provider-neutral contract should Artificer consume from ticket capabilities?

[BjRo]

Confirmed direction

Artificer should use a compatible ticket capability for its full ticket lifecycle: nomination and dependency evidence, claimed-ticket observations, reservation, questions and authorized replies, and claim release. Artificer retains admission limits, durable reservation/correlation, native delivery ownership, and release policy. PR verification remains a code-forge concern.

The scheduled tick may invoke a ticket skill through Codex and consume schema-constrained structured output. We accept the model cost of polling; this revises Artificer's current model-free polling rule. Structured output supplies a parseable result, but Artificer must still validate provider identity, ticket identity, evidence, and effect receipts. Missing, incompatible, malformed, or ambiguous capability results block the affected operation without a direct GitHub fallback. A reservation remains occupied after an uncertain write or launch.

Extend the existing darrow-tickets plugin (which now contains the GitHub adapter) to supply this behavior. A different installed ticket capability may replace it when it advertises the same intent and meets the same evidence, effects, and refusal contract. No plugin-specific path or GitHub ticket command belongs in Artificer's core.

The implementation should preserve the order observe → persist local reservation → claim through the ticket capability → launch delivery. It should carry provider-owned ticket references and canonical URLs through the grant, claim, and recipe handoff; preserve existing GitHub-backed behavior and outstanding claims; and verify the boundary with a fake compatible provider as well as GitHub parity, concurrency, partial-effect, reply, and release cases.

This direction updates the current issue wording that names darrow-tickets-github: the repository now uses darrow-tickets with a GitHub adapter. It also requires updating the Artificer and ticket-management specifications, including the model-free polling invariant.