Cover each exception effect's required and forbidden members

[kikashy]

Goal

Add structural cases for the exception-shape rules that have no negative case: a missing required member for two of the three effects, and a member an effect forbids.

Why

§6.6 makes the shape of an exception depend on the value of another member:

For suppress-rule, targetRule is required and outcome is absent. For force-outcome, outcome is required and targetRule is absent. For escalate, both are absent.

The schema encodes that as three conditional branches:

{
  "if": { "properties": { "effect": { "const": "suppress-rule" } }, "required": ["effect"] },
  "then": { "required": ["targetRule"], "not": { "required": ["outcome"] } }
}

This is the only part of the schema where one member's value changes what other members are allowed, which makes it the part most likely to be implemented as "check each member independently" — and such an implementation passes the corpus today.

The corpus has a positive fixture for all three effects (valid/exception-suppress-rule.json, valid/exception-force-outcome.json, valid/exception-escalate.json) and exactly one negative: structural/force-outcome-missing-outcome.json. So five of the six obligations in the sentence above are unexercised. Nothing tests a suppress-rule without its targetRule, and nothing at all tests the forbidden half — an exception that carries the other effect's member.

The two halves also report differently, which is worth pinning: a missing required member points at the place the member would have occupied (/exceptions/0/targetRule), while a forbidden member present fails the branch's not at the object itself (/exceptions/0).

Scope

• Add fixtures under conformance/structural/ for at least:
  • suppress-rule with no targetRule;
  • suppress-rule that also carries an outcome;
  • force-outcome that also carries a targetRule;
  • escalate that carries an outcome (or a targetRule).
• Add one conformance/manifest.json entry per fixture, layer: "structural", expectedResult: "invalid", specSection: "§6.6", with the code and pointer the repository's validator reports.
• Base each fixture on conformance/valid/exception-suppress-rule.json so the only thing wrong with it is the exception shape.
• Update the document-corpus count statements; a harness test derives the number and its failure message names each stale one.
• Do not change the schema, spec/judgment-pack-core.md, the existing force-outcome-missing-outcome case, or the three valid exception fixtures.

Acceptance criteria

• Each of the four shapes above has a fixture and a manifest entry.
• A missing-member case and a forbidden-member case are both present, with the pointers the validator actually reports for each — they differ, and the manifest should show that.
• No new fixture is invalid for any second reason; the recorded diagnostic is the case's whole point.
• The corpus count statements match the manifest again.
• python -m pip install -r requirements-dev.txt then python -m unittest discover -s tests -v passes.
• Every commit includes a DCO sign-off created with git commit -s.

Contributor learning

Conditional structure: a document format where one field's value decides which other fields are legal, and why "required" and "forbidden" need separate cases even when one sentence states both.