Contract-version doc/code drift sweep

[mijahauan]

Systemic finding from the requirements baseline. Almost every component's prose docs (README / CLAUDE.md / SIGMOND-CONTRACT.md / version --json) lag the code's actual contract/version. The code is contract v0.8 and current; the docs variously still say v0.4/0.5/0.6/0.7, and several have pyproject↔deploy.toml version skew.

Reconcile each to a single honest version/contract string:

• wspr-recorder — WSP-D-090 (SIGMOND-CONTRACT.md v0.4 vs code 0.8)
• psk-recorder — PSK-F-093 (docs v0.4/greenfield-v0.3; removed id-field binding still documented)
• mag-recorder — MAG-F-090 (prose v0.6 vs CONTRACT_VERSION/deploy 0.8)
• codar-sounder — CDR-F-090 (version --json 0.3.1 vs 0.7.0; helpstrings v0.5; docstrings 0.6/0.7 vs 0.8) + CDR-F-091 (deps ka9q-python>=3.11 vs >=3.14)
• hfdl-recorder — HFD-F-091 (prose v0.7/0.6 vs code 0.8)
• hf-tec — CLAUDE.md v0.7 vs contract.py/deploy 0.8
• meteor-scatter — MTS-F-094 (pyproject 0.1.0 vs deploy 0.4.0; contract 0.8 vs 0.7 vs 0.4)
• hf-timestd — pyproject 7.0.0 vs deploy.toml 7.1.0 (intended future-proofing — confirm/align)
• ka9q-python — KQP-Q-010 (pyproject "Development Status :: 4 - Beta" despite being production substrate)

Low-risk, high-clarity hygiene; do as one sweep so the suite reads consistently.

[mijahauan]

Swept and pushed. Prose/doc contract-version references reconciled to the actual code value (v0.8) across all affected repos — committed to each repo's main:
wspr-recorder c0a635c · psk-recorder 9945b08 · mag-recorder 2f29381 · hfdl-recorder 458c8fa · hf-tec 408c395 · codar-sounder 5d34874 · meteor-scatter 3baab2d · ka9q-python ea247d3 (Beta→production classifier).

Also fixed three correctness items the drift had hidden:

• hfdl test_contract.py asserted CONTRACT_VERSION == "0.7" → was failing; now 0.8.
• hfdl cli.py config-unreadable fallback hardcoded "0.4" → 0.8.
• codar __version__ 0.3.1 → 0.7.0 (so version --json matches inventory --json/pyproject/deploy).

Two left for an owner decision (version numbers, not prose):

• codar deploy.toml ka9q-python floor >=3.11.0 vs pyproject >=3.14.0 — has a justifying comment about ensure_channel kwargs; bumping to 3.14 (codar's actual need) also means rewriting that rationale. Recommend 3.14.
• meteor-scatter pyproject 0.1.0 vs deploy.toml 0.4.0 — genuine 'which is the canonical release number' choice.

Caveat: edits are verified unique-string swaps, but each repo's test suite wasn't run here (no pytest in the prod venvs) — worth a uv run pytest per repo before relying on them.