#3274 stagecraft: let users build their own tracker as a separate extension (open tracker kinds, published adapter contract and conformance suite)

Problem

Teams want stagecraft to publish work items to the tracker they already use (Jira, GitHub Issues, an in-house system). Today the only way to get one is to change stagecraft itself, because the set of trackers is closed:

• Fixed kinds. TRACKER_KINDS = ["builtin", "swamp-club", "linear"] (stagecraft/extensions/models/_lib/engine/tracker_binding.ts:29). A factory definition's tracker.kind is checked against that list (definition_schema.ts:739), and so is the tracker binding pinned in each run record. A definition naming any other kind fails validation.
• One hard-coded model type per kind. resolveTrackerBinding (_lib/engine/work_item_ops.ts) refuses a tracker instance whose model type is not exactly TRACKER_TYPES[kind]. An @acme/jira model is rejected at validate and at start, and a third party cannot use the @swamp/stagecraft/* type names.
• Private building blocks. The adapter contract (_lib/tracker/core/adapter.ts), trackerMethods (tracker_methods.ts) and the conformance suite (tracker_conformance.ts) live under stagecraft's _lib/ and are not exported. Another extension would have to copy them and keep its copy in step by hand.
• No shipped docs. The contract is described well in stagecraft/DESIGN.md ("Trackers": the eight operations, capabilities, origin, conformance), but the manifest ships only README.md, and that document is written for stagecraft contributors.

Reported by an Enterprise team in #3216: "Build a Jira tracker adapter ourselves: possible, but the adapter interface is not documented for third parties."

Direction

This is the intended direction (Seth, 2026-10-11): users can build their own tracker as a separate extension, and stagecraft treats it the same as the built-in, Linear and Lab adapters.

What it needs (for the plan to settle)

1. An open set of trackers. Bind a factory to any tracker model that meets the contract, not to a fixed list of kinds. Decide what a definition names in place of kind (a model type, or a capability check against the instance), and how existing definitions and pinned run records upgrade. Use the upgrade-on-read chain from #3194/#3190, and mind #3196: validate does not apply upgrades yet.
2. A published contract. Export the adapter types, trackerMethods and the conformance suite so another extension can import them, from stagecraft or a small library extension. Decide how that surface is versioned, since it becomes a public API.
3. A conformance check a third party can run. The same suite stagecraft's own adapters pass, runnable against an external adapter and its fake.
4. Documentation that ships. A guide to writing a tracker extension: the eight operations, capabilities, origin, credentials and redaction, idempotency keys. Include a worked example, ideally a minimal one in examples/.
5. The skill and the studio handle an external tracker the same as a built-in one: the skill's command checks (#2711) and the studio's Ticket tab.
6. The built-in, Linear and Lab adapters move onto the public contract, so it is proven by the adapters we ship.

Out of scope

• A Jira adapter itself. Writing one, or a minimal external example, is a good proof of the contract, but shipping Jira support is a separate decision.
• #3216's immediate need (caller-supplied ids on the built-in tracker, display case, docs on hand-started work items), which is handled in #3216.

Related: #3216, #2664 (tracker adapter contract), #2793 (the tracker seam), #2711, #3194, #3196.