fix(schema): catch vault-v1 proposal kind enum up to revision 1.4 (add_lens/update_lens)

[claude-dataviking]

What

Contract-truth fix: add_lens/update_lens shipped with the revision-1.4 positioning-lens feature (traitprint.proposals PROPOSAL_KINDS, the proposals CLI, traitprint proposals contract) but were never added to docs/schema/vault-v1/vault-v1.schema.json's $defs/proposal kind enum — so external validators consuming the JSON Schema directly rejected lens proposals the CLI accepts. Found as a side observation during the lens-capability audit (see #94).

How it's recorded

This documents already-shipped behavior — no validation semantics change and no new contract revision. The schema's enum had never been amended before (it was written once in the initial v1 commit), so there was no prior enum-addition precedent; the convention that does exist is the "Revision N:" annotation style, so this is recorded as a correction to the 1.4 record:

• vault-v1.schema.json: enum gains the two kinds, the kind property gains a "Revision 1.4: ... caught up in a later correction" description, and the $comment's 1.4 sentence is amended.
• docs/schema/vault-v1/README.md: the 1.4 revision-history entry is amended the same way.
• CHANGELOG.md: Fixed entry under [Unreleased].

Drift guard

No test pinned the schema's proposal enums to the code — exactly how this slipped. New TestSchemaProposalEnums in tests/test_doc_truth.py pins the schema's kind and status enums to PROPOSAL_KINDS/PROPOSAL_STATUSES, so shipping a new proposal kind without updating the contract schema now fails CI.

Cloud note (per CLAUDE.md "don't drift from cloud"): this changes no proposals.py behavior; it only makes the schema document what local validation already does. The separately-queued cloud fix (adding lens kinds to the hosted vault_propose allowlist) is unaffected.

Gates

• pytest -q: 1030 passed, 3 skipped
• ruff check src/ tests/: clean
• mypy src/: clean

🤖 Generated with Claude Code