feat(registry): runtime Standard Schema validation (insert/update/command)

[grrowl]

Stacked on #19 (base branch is feat/sync-schema, not main). Review #19 first; this PR's diff is only the validation layer.

What

The base PR ships the object schema with the Standard Schema slots typed but not enforced at runtime (a tombstone). This PR wires the runtime gate:

• insert.schema checks the full-row cols. It also infers the collection's Row, so you drop the <Row> generic.
• update.schema checks the partial patch. You pass a partial schema (e.g. Message.partial()) because an update sends only the changed fields. This is the "go further" piece — a full-row schema would reject every valid partial.
• command schema checks args.
• delete needs none (the key is wire-checked, and the pk was validated at insert).

Each runs in authorize, before the write, and throws to reject the frame. It is a gate, not a parser (ADR-0014): the original value flows to handlers, so transforms/defaults/coercion are not applied — rewriting an optimistically-applied row would manufacture divergence.

Any ~standard library works (zod 3.24+, valibot, arktype); the framework adds no validator dependency.

Schema home

The row schema lives on mutations.insert.schema (it validates inserts and types Row), per the discussion on #19 — the collection's "default" schema was only ever used by insert. Inference from the nested insert.schema was proven with a tsc --strict spike before implementing.

Tests

tests/schema-validation.test.ts drives a validated collection and a requireBody command through a hand-rolled Standard Schema (no validator dep): bad insert/update/args are rejected (mutation rejections carry the validation message; command rejections are generic per ADR-0012), good ones commit.

Verification

• tsc --noEmit: 0 errors.
• vitest run: 177/177 (171 base + 6 new).

Recipe

recipes/zod-standard-schema-collections.md documents it (insert + partial update + command, the gate rule), in the project's plain style.

🤖 Generated with Claude Code