Remove exclusions.json and prohibit card/mechanic denylists

[ninthworld]

Goal

Remove crates/sage-engine/data/exclusions.json and make missing mechanics implementation work, never a reason to classify a card or mechanic as deliberately unsupported.

Context and evidence

Current behavior:

• data/exclusions.json is a hand-maintained registry of cards and mechanics considered “out of scope,” each paired with a blocker.
• crates/sage-engine/src/compat.rs embeds that registry and generates an “Excluded” section in docs/generated/compatibility.md.
• docs/compatibility-report.md, docs/brief.md, docs/card-schema.md, crates/sage-engine/AGENTS.md, tests, and code comments establish the exclusion list as the accepted place to record an engine limitation.
• This creates the wrong incentive: a missing IR primitive or rules mechanic can justify not adding a card instead of creating the capability the card requires.

The catalog may still claim only the verified cards it actually supports. What must disappear is the notion that unsupported cards or mechanics belong in a curated exclusion registry. If a card cannot be authored because the engine lacks a mechanic, the work is to implement that mechanic and track that affirmative work as an issue.

Related history: the compatibility report and exclusion registry were introduced under #258.

Scope

• Delete crates/sage-engine/data/exclusions.json.
• Remove the exclusion data model, parser, embedding, rendering, validation, tests, and generator inputs from sage-engine.
• Make the compatibility report a deterministic inventory of supported catalog cards only.
• Remove or rewrite repository documentation, agent guidance, tests, and comments that treat an exclusion list as authoritative or recommend recording a limitation there.
• Convert the blockers represented by the current exclusion entries into affirmative mechanic/card implementation work. Existing knowledge must not be lost merely because the registry is deleted.
• Add binding contributor guidance: when a target card is blocked by missing rules vocabulary, extend the engine/IR and its exhaustive consumers with tests; do not add the card to an exclusion, unsupported, deferred, exception, denylist, or equivalent registry.
• Ensure no generated artifact, alternate data format, source constant, documentation table, or renamed file replaces exclusions.json as a curated list used to justify not implementing cards.

Acceptance criteria

• crates/sage-engine/data/exclusions.json no longer exists.
• No engine API, generator, test, or build step reads or models curated exclusions.
• docs/generated/compatibility.md contains the complete supported catalog inventory and no “Excluded,” “Unsupported,” “Deferred,” or equivalent denylist section.
• make compat derives its output from the catalog alone and remains deterministic.
• Every repository instruction that currently says to add or preserve an exclusion instead says to implement the missing mechanic and add the blocked card, or to open/link affirmative implementation work when that cannot fit in the current change.
• Every current exclusion entry is accounted for by implemented support or linked affirmative implementation issue(s); deleting the JSON does not silently discard known engine gaps.
• Repository guidance explicitly prohibits reintroducing a curated card/mechanic exclusion registry under another filename, format, generated section, or euphemism.
• Tests prove the compatibility report includes every catalog card exactly once and cannot drift, without accepting any exclusion input.
• All stale references to exclusions.json and the old exclusion policy are removed or rewritten, including engine docs, the brief, schema documentation, ADR commentary where appropriate, source comments, and tests.
• make check and make verify pass.

Test and validation evidence

• Unit tests for deterministic, catalog-only compatibility rendering.
• Freshness test for docs/generated/compatibility.md.
• Repository search confirming there is no remaining exclusion-registry path or instruction to record missing mechanics as exclusions.
• make check.
• make verify.

Dependencies and sequencing

None. This should first inventory the current entries and preserve each as affirmative implementation work, then remove the registry and update the report/policy in the same coherent change.

Estimated scope

Large — the code removal is focused, but the policy is embedded across engine APIs, generated output, tests, product/engine documentation, schema notes, ADR commentary, and the current mechanic backlog. Split the affirmative mechanic implementations into linked issues where needed, while keeping deletion of the registry and enforcement of the new policy atomic.

Risks and constraints

• Do not weaken the project’s honest claim: SAGE supports only the verified catalog slice, not every Magic card.
• Do not erase known mechanics gaps without preserving them as affirmative work.
• Do not replace the JSON with another centralized registry or a generated list of reasons cards are unsupported.
• Engine additions remain pure and server-authoritative, and every rules behavior change requires tests.
• Preserve the project’s legal constraint against exact Oracle text and official presentation assets.

Non-goals

• Claiming full game or set coverage before it exists.
• Adding unverified cards to the supported compatibility report.
• Requiring every missing mechanic to be implemented in the same PR that removes the registry; large mechanic work may be tracked in linked implementation issues, but it may not be converted back into an exclusion list.

Documentation impact

Update crates/sage-engine/AGENTS.md, docs/brief.md, docs/compatibility-report.md, relevant portions of docs/card-schema.md, generated compatibility documentation, and stale ADR/source commentary. Document the durable rule that missing mechanics create implementation obligations, not exclusions.

[ninthworld]

Still valid and untouched, and the ground under it has shifted in this issue's favour.

Current state on main at 47e26cc. crates/sage-engine/data/exclusions.json holds 45
entries (36 when this was written — the M19 tranche split coarse families into narrower residuals
as each was partly built). compat.rs still embeds it and docs/generated/compatibility.md:316
still renders ## Excluded (45) beside ## Supported cards (299).

Two of the three live instructions telling contributors to maintain the registry are gone.
This issue's hardest part was never the deletion — it was that other open issues gave the opposite
instruction, so a contributor following the tracker would have been re-filling the file while this
one waited to empty it:

• engine: authorable nonsense the validator accepts, and five gaps the M19 tranche left behind #776's acceptance criterion said two vocabulary gaps must be "named by an entry in
  exclusions.json". Closed.
• engine: plan and implement the next high-leverage compatibility tranche #706's said "make compat removes or narrows the corresponding exclusions" and "unselected
  families remain honestly excluded". Closed as delivered.
• What remains is the repository's own guidance — crates/sage-engine/AGENTS.md, docs/brief.md,
  docs/card-schema.md, docs/compatibility-report.md, and ADR commentary — which is exactly the
  scope this issue already owns.

One thing the tranche demonstrated in this issue's favour, and one against.

In favour: the 45 entries are no longer a list of things nobody tried. Most were narrowed by
building the family — Damage prevention beyond a blanket shield for the turn is what is left of
what used to read Damage prevention, and ADR 0019 records why the next event costs what it
costs. That is the affirmative knowledge this issue asks to preserve, and it is already written
down outside the JSON, in module docs and ADRs, where it reads better.

Against: those 45 residual sentences are unusually precise, and they are load-bearing for the
project's honesty claim. Deleting the file without a home for that precision would trade an
incentive problem for a truthfulness problem. The acceptance criterion "every current exclusion
entry is accounted for by implemented support or linked affirmative implementation issue(s)" is
the one to hold the line on — and with 45 entries, the realistic shape is a small number of
grouped implementation issues plus a rewritten compatibility report that states what the catalog
does, not a 45-way issue split.

Sequencing note: #711 is the only other open issue, and it touches none of the same files. This
can go first.