docs(agent-context): align verify skill and Java docs to ADR-0015 validator removal

[dmealing]

Intent

Audit the rest of the MetaObjects agent-context corpus (the metaobjects-* skill bodies + per-language reference fragments + README) for the same defect class fixed in issue #1: docs that conflate a generic invariant (true for every adopter) with a project-specific binding (which migration tool / framework / paths), or that guess a binding, leading an AI agent to hand-write a derivable artifact (e.g. a raw ALTER TABLE) and silently reintroduce drift. A delegated review found the corpus broadly clean: per-language reference fragments are installed CONDITIONALLY per the resolved stack, so their stack-specificity is correct by design and was deliberately NOT flagged; LLM callers are explicitly bring-your-own; the migration-is-metadata-derived framing is intact across all five ports. The single genuine consistency fix: verify/SKILL.md asserted the JVM runtime startup validator 'catches generated-table drift at app boot' as a flat fact, but wiring that validator is an opt-in adopter binding -- migration.md already hedges the same capability ('can catch'), so this aligns verify/SKILL.md to it ('can catch ... an optional complementary check (if your project wires one)'). The 4 cross-stack agent-context conformance fixtures were regenerated because the skill body is installed for every stack (verified: conformance + root/sdk byte-identity gates green). Deliberately did NOT add any config field, did NOT touch the per-language framework assumptions (correct stack bindings), and did NOT alter the ADR-0015 migration framing.

What Changed

• Hedged the JVM runtime startup-validator claim in agent-context/skills/metaobjects-verify/SKILL.md from a flat "catches generated-table drift at app boot" fact to "can catch ... an optional complementary check (if your project wires one)", matching migration.md's existing phrasing — and regenerated the 4 cross-stack agent-context conformance fixtures since the skill body installs for every stack.
• Synced docs/features/migrations-and-drift.md, docs/ports/java.md, and README.md to stop asserting the removed MetaClassDBValidatorService startup validator as a hard guarantee, consistent with ADR-0015 Decision 2.

Risk Assessment

✅ Low: Pure documentation wording change that softens one over-stated claim and propagates it byte-identically to the four conformance fixtures (verified matching), with no code, behavior, or contract impact.

Testing

Baseline bun install then ran the agent-context byte-identity conformance gate (4 pass) plus the drift/content-root/assemble gates (13 pass). Because the end-user surface is the skill markdown an AI agent reads, I rendered the assembled metaobjects-verify SKILL.md through the real assemble() pipeline for the ts/java/python stacks and captured the corrected --db bullet — confirming the hedge ships identically to every stack, matches migration.md's existing wording, and leaves no un-hedged startup-validator assertion anywhere in the corpus. All checks green; worktree left clean.

Evidence: Assembled metaobjects-verify --db bullet (rendered per stack — the text an AI agent receives)

===== STACK: ts-react-tanstack / java-react / python ===== - --db — schema drift. ... On the JVM ports a runtime startup validator can catch generated-table drift at app boot as an optional complementary check (if your project wires one), but the authoritative DB-vs-metadata gate is the Node verify --db.

===== STACK: ts-react-tanstack =====
- **`--db`** — schema drift. Introspects the live database and fails if it has
  diverged from metadata. This is a **schema concern, so it is the Node toolchain's
  job regardless of your server language** (see migrations below). On the JVM ports
  a runtime startup validator *can* catch generated-table drift at app boot as an
  optional complementary check (if your project wires one), but the authoritative
  DB-vs-metadata gate is the Node `verify --db`.

===== STACK: java-react =====
- **`--db`** — schema drift. Introspects the live database and fails if it has
  diverged from metadata. This is a **schema concern, so it is the Node toolchain's
  job regardless of your server language** (see migrations below). On the JVM ports
  a runtime startup validator *can* catch generated-table drift at app boot as an
  optional complementary check (if your project wires one), but the authoritative
  DB-vs-metadata gate is the Node `verify --db`.

===== STACK: python =====
- **`--db`** — schema drift. Introspects the live database and fails if it has
  diverged from metadata. This is a **schema concern, so it is the Node toolchain's
  job regardless of your server language** (see migrations below). On the JVM ports
  a runtime startup validator *can* catch generated-table drift at app boot as an
  optional complementary check (if your project wires one), but the authoritative
  DB-vs-metadata gate is the Node `verify --db`.

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

✅ **Review** - passed

✅ No issues found.

✅ **Test** - passed

✅ No issues found.

• cd server/typescript/packages/sdk && bun test test/agent-context-conformance.test.ts — 4 pass (byte-identity of assembled skill vs the 4 regenerated fixtures across stacks)
• bun test test/agent-context/drift.test.ts test/agent-context/content-root.test.ts test/agent-context/assemble.test.ts — 13 pass
• Rendered the assembled metaobjects-verify/SKILL.md via assemble()/makeStack() for ts-react-tanstack, java-react, and python stacks; confirmed the corrected hedged --db bullet appears in all three (the text an AI agent actually consumes)
• grep audit: confirmed migration.md uses the matching 'can catch ... complementary check' hedge and that no un-hedged 'catches generated-table drift at app boot' string remains in agent-context/ source or fixtures/agent-context-conformance/

🔧 **Document** - 1 issue found → auto-fixed ✅

• ℹ️ docs/features/migrations-and-drift.md:16 - Pre-existing, out-of-scope: docs/features/migrations-and-drift.md (lines 16, 111, 116) — and README.md, server/java/README.md, docs/ports/java.md — still assert the JVM startup validator catches generated-table drift at app startup as a flat fact and attribute it to MetaClassDBValidatorService, which no longer exists in source (removed per ADR-0015 Decision 2). This is the same flat-fact/conflation defect class the audited change corrected in the agent-context corpus, but fixing it requires the broader ADR-0015 MetaClassDBValidatorService-removal correction the author deliberately scoped out, so it needs a human call rather than a silent edit.

🔧 Fix: sync Java migration/drift docs to ADR-0015 validator removal
✅ Re-checked - no issues remain.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.