The corpus was re-measured with `ckc sizes` on all 36 apps. The same eleven
refuse; nothing closed at the app level, but most of the LEDGER did, and seven
of the ten trap files had drifted away from the compiler they describe.

`List::filter` / `map` / `contains` / `len` and `++` all resolve now. The E0728
rows that dominated five trap files are gone, and what stands in their place is
the bound arithmetic behind them — `[v, ..rest]` narrows, `xs ++ [v]` widens,
and neither fits the fold's own parameter (E0702 / E0723). `E0706` no longer
fires anywhere. `Equals` is the last missing list row; `fold` the only other
absent method. Corrected inventories, dated and reproducible, in each trap.md.

Why they drifted is the structural finding, recorded in plan.md §4d:
`ck_driver/tests/corpus.rs` reconciles the RESOLUTION closure only, by design.
Only `snake` and `algorithms_Dijkstra_trapped` refuse at resolution; every other
refusal is typecheck, so every typecheck claim in every trap.md is unreconciled
prose. Nothing was watching them.

`types` was the undeclared refusal. `Eq` is a stale spelling — the live roster
is `Equals` (`DERIVABLE_TRAITS = ["Equals", "Hash"]`) — so E0753 x2 was an
authoring bug in the app and is fixed. The remaining four are real gaps (a named
lowercase parameter is not a field on the value; `{}::<T> with v` is read as an
anonymous record) and are declared in a new `tests/corpus/types/trap.md`.

`Grammar.ckx`'s `max 128` on `list_lit` is real now (owner ruling 4). The parser
counts — a literal's elements are all visible — and the 129th is E0148.
`ck_parser::LIST_LIT_MAX_ITEMS` is the enforcement and G-P in
`grammar_structure.rs` reconciles it against the grammar's own text, so declared
and enforced are one number. Two cells pin both directions:
`list_literal_at_the_declared_maximum` (128, runs 7) and
`..._past_the_declared_maximum_refuses` (129, typecheck E0148).
CELL_COUNT 437 -> 439. The other 28 `max N` bounds remain unenforced and are
named as such, in the gate and in plan.md.

CLAUDE.md §6 said `docs/` "stays in the CkLang repo and is the single source of
truth". It exists in neither repo, deleted here in 07a49fef, recoverable only
at 07a49fef^. The section now says that, and says what to cite instead. plan.md
counted "two doc comments" still linking `../../../../docs/`; the real count was
124 occurrences across 29 files in `src/`, plus 8 in `tests/`. All delinked —
the prose citation stays, the dead link goes.

Ratchets: CELL_COUNT 437 -> 439 (two cells, both marked, neither BROKEN, so
BROKEN_CELL_COUNT and UNMARKED_CELL_COUNT do not move). No threshold raised.

Gates run here: `cargo fmt --check` clean; `clippy --workspace --all-targets
-D warnings` 0 warnings; `--test corpus`, `--test architecture` (38),
`--test grammar_structure` (7), `--test grammar_stage1` (9), and the unit suites
of ck_parser / ck_lex / ck_syntax / ck_types / ck_resolve / ck_load / ck_cktest
all green. `--test capability` was NOT run — it spawns containers and is the
main session's to run; the two new cells were verified by hand instead
(`ckc check` for E0148, `ckc disassemble` + the linked binary for exit 7).

@@ -47,0 +54,4 @@
+/// the enforcement (E0148 on the 129th element). Deliberately narrow: the other
+/// 28 `max N` bounds are unenforced, and each gains a row here when it lands.
+#[test]
+fn the_parser_enforces_the_declared_list_literal_bound() {

@@ -623,9 +629,24 @@ impl Parser {
                 self.emit_error_at_cursor("E0075", "expected `]` to close list literal");
                 break;
             }
+            if items == LIST_LIT_MAX_ITEMS && !over_cap_reported {

@@ -33,6 +33,7 @@ pub struct ParseOutput {
     pub diagnostics: Vec<Diagnostic>,
 }
 
+pub use expr::LIST_LIT_MAX_ITEMS;