fix(dsl): v0.11.0 -> v0.14.0 grammar migration (0.14.1)

[aaronstevenwhite]

Summary

Register the v0.11.0 -> v0.14.0 grammar migration hop that the 0.14.0 release should have shipped. v0.14.0 changed the grammar (added family_call_arg and list_arg productions to _draw_arg) but no migration was written; this restores the invariant that every grammar-changing release ships a corresponding hop in src/quivers/cli/migrations/.

Motivation

The migration chain in src/quivers/cli/migrations/__init__.py is the tool that lets a user with a .qvr file written against any historical grammar walk their source forward through every intermediate release to head-of-tree via qvr migrate --from <TAG> --to HEAD. The CI gate that keeps check_chain_coverage(CHAIN, COVERAGE) clean (no removed rules without a converter) ensures that migration is real, not aspirational.

v0.14.0 was tagged without adding to CHAIN or MIGRATORS. The chain still terminated at v0.11.0 and a caller pointing at v0.14.0 grammar would fall out of the composition. This PR closes that gap.

Changes

• src/quivers/cli/migrations/v0_11_0_to_v0_14_0.py (new): the hop between the two grammar revisions. v0.14.0 adds two productions to the _draw_arg choice (family_call_arg, list_arg) and touches no other rule. Every v0.11.0 source that parses under v0.11.0 also parses under v0.14.0, so migrate is byte-identity. SOURCE_RULE_COVERAGE = frozenset() reflects "no removed rules to cover", matching the extension-only pattern in v0_9_0_to_v0_10_0.py.
• src/quivers/cli/migrations/__init__.py: append "v0.14.0" to CHAIN, register the hop in MIGRATORS and COVERAGE.
• grammars/qvr/vcs/parsers/v0.14.0/ (new): tree-sitter parser snapshot for the v0.14.0 grammar (qvr.dylib + regenerated parser.c, grammar.json, node-types.json).
• grammars/qvr/vcs/.panproto/: panproto VCS object store rewritten by build_schemas.py --reset, with the v0.14.0 commit added on top of the v0.11.0 commit (v0.14.0 introduces 2 rules, 5 field edges).

API impact

• No API change.
• Additive only (new symbols, no existing behaviour changed).
• Breaking change. Migration notes:

The public CHAIN tuple lengthens by one. Every previously-composed migration path still works and yields the same output. Callers targeting qvr migrate --to HEAD now traverse v0.11.0 -> v0.14.0 as an extra hop, but the hop is byte-identity.

Tests

• qvr migrate --check returns exit 0 for the full chain; the v0.11.0 -> v0.14.0 pair reports added_rules: family_call_arg, list_arg and uncovered_removed: [].
• compose_migration("v0.2.0", "v0.14.0") composes without error.
• Round-trip check: a v0.11.0-shaped source pipes byte-identically through the v0.11.0 -> v0.14.0 hop.
• pytest tests/test_doc_blocks.py -q runs 160 tracked .qvr fenced fixtures against HEAD grammar: 160 passed.
• Rebuild script invariants: python grammars/qvr/vcs/build_schemas.py --reset and python grammars/qvr/vcs/build_parsers.py succeed and produce the expected v0.14.0 snapshot.
• Tree-sitter fixtures updated (if grammars/qvr/ changed).

Documentation

• Docstrings updated for changed public API.
• User-facing pages under docs/ updated.
• docs/developer/changelog.md has a Unreleased entry for this change.
• Denotational semantics under docs/semantics/ updated (if the change affects the meaning of any DSL construct).

The migration itself does not add behaviour that needs user-facing documentation beyond the existing qvr migrate CLI help. Follow-up PR can add a CHANGELOG entry if maintainers want the migration fix noted in the next release notes.

Checklist

• Commit is focused and has a descriptive message.
• No backward-compatibility shims added.
• Comments describe the code as it stands; no references to prior states or removed code.
• No secrets, credentials, or large binary artefacts in the diff. (The .panproto/objects/** files are content-addressed schema snapshots produced by build_schemas.py --reset on every grammar bump; that's the accepted repo pattern.)