docs: codify feature-acceptance criterion (LLM-author utility)

Adds DESIGN.md "Feature-acceptance criterion" as a top-level section:
a feature ships only if (1) an LLM author naturally produces code
that uses it, and (2) it measurably improves correctness or removes
redundancy. Aesthetic appeal and human ergonomics do not count.

Mirrored in CLAUDE.md as "Feature acceptance: LLM utility", paired
with the existing "Design rationale != implementation effort". The
two together narrow valid feature rationales to one thing: what the
LLM author gets out of the feature.

Trigger: the typeclass-design conversation around 22a. Rule was
implicit in many past decisions (Decision 1's JSON-over-text choice,
Decision 10's "what LLMs are good at" reasoning) but never stated
as a feature-gate. Codifying it now means future feature proposals
get evaluated against an articulated criterion instead of being
re-derived each time.

Documentation-only; no Rust, schema, or bench changes. Test state
288/0/3 unchanged.

CLAUDE.md

@@ -90,6 +90,19 @@ locality (modes belong to fn-parameter positions, not to types in
 general), and I retroactively had to add it. JOURNAL entries from
 2026-05-08 record the lesson.
 
+### Feature acceptance: LLM utility
+
+When deciding whether a proposed feature ships, the test is
+whether an LLM author naturally produces code that uses it AND
+whether the feature measurably improves correctness or removes
+redundancy. Aesthetic appeal does not count; neither does human
+ergonomics. The full criterion lives in DESIGN.md
+("Feature-acceptance criterion").
+
+This is the positive complement to the rule above. Together they
+narrow the space of valid feature rationales to one thing: what
+AILang's actual user — the LLM author — gets out of it.
+
 ### Direction freedom
 
 I have authority to choose the next iter, refactor, or feature