check: the enum-bound refusal follows provenance through a table closure (#605)

[rowan-claude]

Closes #605.

[E.Max]T was refused in a table body and a union arm by its SPELLING, while SPEC-TABLES.md §2.4 and §11 state the refusal on the bound's PROVENANCE. [E.Count]T and [N]T under a const N that folds from either compiled clean, and each one reopens the positional class §4.1 counts as closed.

Red first (86d0073)

test/tables/enumbound holds one unit a shape. Against that commit, ./bin/schema check on each file:

ArmConstCount.schema    COMPILES (exit 0)
ArmConstMax.schema      COMPILES (exit 0)
ArmCount.schema         COMPILES (exit 0)
ArmFolded.schema        COMPILES (exit 0)
ArmMax.schema           REFUSED, naming neither the arm nor the table
BodyConstCount.schema   COMPILES (exit 0)
BodyConstMax.schema     COMPILES (exit 0)
BodyCount.schema        COMPILES (exit 0)
BodyFolded.schema       COMPILES (exit 0)
BodyMax.schema          REFUSED, naming not the table
ControlPacket.schema    COMPILES (exit 0)
ControlPlain.schema     COMPILES (exit 0)
ControlTypeHeld.schema  COMPILES (exit 0)

TestEnumBoundProvenanceCorpus reads the directory and holds each file to its answer. At the red-first commit all ten refused rows fail and the three controls pass:

--- FAIL: TestEnumBoundProvenanceCorpus (0.00s)
    BodyMax.schema: no diagnostic says "table Fleet: field ships"
    BodyCount.schema compiled in a table closure, and a variant inserted in the middle of ShipType would land every later element one slot off in every file already written
    BodyConstMax.schema compiled in a table closure, ...
    BodyConstCount.schema compiled in a table closure, ...
    BodyFolded.schema compiled in a table closure, ...
    ArmMax.schema: no diagnostic says "union Payload: arm ships"
    ArmMax.schema: no diagnostic says "table Fleet's field payload reaches Payload"
    ArmCount.schema compiled in a table closure, ...
    ArmConstMax.schema compiled in a table closure, ...
    ArmConstCount.schema compiled in a table closure, ...
    ArmFolded.schema compiled in a table closure, ...

The checker (66e4cdc)

enumBoundProvenance follows a bound to the enum it folds from, through named constants and constant arithmetic at any depth (SPEC.md §4.2), carrying its own visiting guard over the constant graph. It looks at an ENUM alone: a flags bound is refused by its own rule, and a bound reaching neither is a plain positional array that stands wherever it is spelled.

checkPositionalEnumBoundInClosure runs once the closure is known, which is what lets a union arm's diagnostic name the table that reaches the union, as #572's closure refusal names the edge that pulled a type in.

The walk is the fence. It starts at TABLE bodies and descends UNIONS alone.

• A type a table closure reaches is never visited, so Owner ruling wanted: an enum-extent array in a type rides a different table-wire kind depending on whether a table holds the type #606 keeps its ruling. Widening this walk to type bodies is the one edit that would decide it, and it is not made here.
• A type no table reaches is not in the closure at all, so the packet wire is untouched.

The diagnostics, green:

table Fleet: field ships: [SlotCount]int32 is refused in a table body, because
the bound SlotCount folds from ShipType.Max. An ordinal-indexed array is a
POSITIONAL vocabulary, so inserting a variant in the middle of ShipType lands
every later element one slot off in every file already written, with nothing on
the wire that could say so. Instead spell it [ShipType]int32, whose slots ride
by variant name (docs/SPEC-TABLES.md §2.4, §11)

union Payload: arm ships: [SlotCount]int32 is refused in a union arm, because
the bound SlotCount folds from ShipType.Count, and table Fleet's field payload
reaches Payload. An ordinal-indexed array is a POSITIONAL vocabulary, ...

exprSpelling now renders constant arithmetic, so a bound like [Grade.Max + 1] is quoted back as the source spells it instead of as the placeholder N.

What the refusal caught in the tree

test/tables/V1.schema and V2.schema sized tally in both generations and ledger in V1 as [Grade.Max + 1]int32: a positional array in a table body whose bound folds from an enum, which is exactly the shape the page says is refused. Two evolution fixtures rested on the gap.

Both keep their extents, 3 in V1 and 4 in V2, spelled now as the plain constants TallySlots and LedgerSlots, so every generation the evolution test exercises is unmoved: the growing bound, the clamped count on the narrow read, and V1-positional against V2-keyed for ledger. schema fmt re-canonicalized the attribute column in both files. No wire byte and no golden moved.

Controls (53bb48d)

make check-enum-bound-negative-control, wired into make test beside check-zero-range-negative-control. It compiles no C++.

The gate: every refused shape is refused, each diagnostic names the field or the arm, the enum, the constant where the bound reaches the enum through one, and [E]T as the fix; each arm row names the table that reaches the union.

The three positive controls compile: ControlPacket (a packet-only unit spelling all five bounds), ControlPlain (a bound that folds from no enum, in a table body and a union arm), ControlTypeHeld (a type a table reaches, #606's case).

The negative control is §2.4's own: it removes the CONSTANT FOLD from the bound check through go build -overlay, writing no tracked file. It is targeted rather than blanket, so the four direct spellings must stay refused under the same sabotage.

gate: ten shapes refused on the bound's provenance, three controls compile
negative control: without the constant fold, six folded rows compile clean and the four direct spellings stay refused

The page (ea4a622)

• SPEC-TABLES.md §2.4's CHECKER STATUS paragraph, which carried its own instruction to be deleted by this PR, now states one thing: the refusal reads the bound's provenance and not its text. §11's line says the same in its register.
• Both RULING STATUS lines for Owner ruling wanted: an enum-extent array in a type rides a different table-wire kind depending on whether a table holds the type #606 stay exactly as they were.
• VERSIONING.md: the check: the [E.Max]T refusal in a table body (§2.4, §11) is not made #540 row leaves "Owed before 3.0.0", whose contract is a claim the page makes with the repository not yet behind it. The evolution table's "a keyed array made positional" row named the table body alone, which The [E.Max]T refusal follows the bound's provenance and reaches every type a table closure holds (#540, one body away) #605 flagged; it now names the union arm and states the provenance rule.
• USAGE.md carried the same split as an italic caveat. A caveat that is no longer true is worse than one out of scope, so it is replaced by what the diagnostic says. The Owner ruling wanted: an enum-extent array in a type rides a different table-wire kind depending on whether a table holds the type #606 caveat beside it stays.

Silences for the owner

1. The type-held case is untouched and undecided. ControlTypeHeld.schema pins that a type a table reaches keeps the spelling, so whichever way Owner ruling wanted: an enum-extent array in a type rides a different table-wire kind depending on whether a table holds the type #606 goes, the fixture names the case rather than leaving it implicit. Deleting that control is the edit that reopens the question.
2. tally's fixture intent narrowed. Its comment read "sized off Grade.Max + 1, which grows when Grade does". The bound can no longer fold from Grade in a table body, so the fixture now grows 3 to 4 by a plain constant. If the intent was specifically "the bound tracks the enum", the table-wire answer for that is [Grade]int32, keyed, which is a different fixture and a wire move; I did not make it.
3. ledger was the "a keyed array made positional" evolution fixture and its V1 side is now a positional array with a non-enum bound. The wire evolution it exercises, a positional kind read as a keyed one, is unchanged; what it no longer demonstrates is that side being spelled from the enum, because that spelling is now refused.
4. A union arm one union deeper is walked but not pinned. checkUnionArmBounds descends an arm that is itself a union, but a corpus unit for it is refused first by "no table reaches" for an unrelated reason, so no row holds that path.

Toolchain: go test ./... green, make check green, the diagnostics suite green, make test run to the C# leg (#599, dotnet absent).

🤖 Generated with Claude Code

Two things the merge carried, and neither is this issue's

goldens: re-pin maps/TextTable.cpp. main is red at 19a2372 on its own CI run 34081461383 and was green at bb5f3bd. #625 moved internal/codegen/cpptable/json.go and re-pinned the map goldens it knew about, DepthTable.cpp, FleetTable.cpp and RowsTable.cpp, each by the same 91 lines; Text.schema and its golden landed in #626, which merged after #625's branch was cut, so maps/TextTable.cpp never got the re-pin and make tables-block-zero-cost reports it moved. The file here is the generator's own output, copied by the path make update-goldens copies it, with no hand edit. Copying the whole maps directory moves this one file and nothing else, which is what says the other three were already current. This commit belongs to #625/#626 and is here only because this branch cannot be green without it.

No golden moved for this change. go test ./internal/goldens is green, the C++ tables leg byte-compares every pinned wire golden and passes, and the tree is clean after generation, so make update-goldens was not needed for anything in this PR.