Resolve stable v1 AEAD verifier mismatch before wiring Prophet lane fixtures

[mdheller]

Summary

Current main has a mismatch between repo documentation/spec language and the strict fixture verifier implementation.

Observed:

• README/spec posture says stable v1 fixture verification uses XChaCha20-Poly1305 with explicit per-frame nonces.
• tools/verify_fixtures_strict.py on current main still computes BLAKE2b-MAC over AAD.

This blocks safely wiring the Prophet evidence.v1 lane fixture vectors into strict verification.

Why this matters

The Prophet lane-1 release fixture pack was generated under the XChaCha20-Poly1305 stable-v1 posture described in README/spec. If we add the fixture file to the current strict verifier set before resolving the verifier mismatch, the verification path will reject otherwise intended XChaCha vectors.

Acceptance criteria

• Decide the normative verifier algorithm for current stable v1 fixtures.
• Update README/spec/verifier if any are stale.
• Ensure tools/verify_fixtures_strict.py behavior matches the documented stable v1 posture.
• Only then wire vectors_hex_prophet_lane1.txt into strict verification.

Related issues

• Add Prophet evidence.v1 lane schemas and fixture vectors #50
• Extend strict fixture verifier and Rust/Go parity checks for Prophet evidence.v1 #54
• Add JCS + BLAKE3 receipt vectors for Prophet evidence lane #55

[mdheller]

Update from follow-up inspection: Rust and Go fixture tests on current main also compute BLAKE2b-MAC for existing fixture tags, and the strict verifier matches that implementation path. So the safest short-term interpretation is that the current stable fixture test path is BLAKE2b-MAC in practice, while README/spec language still mentions XChaCha20-Poly1305. This issue should resolve the documentation/spec/code mismatch explicitly before any new Prophet lane fixtures are wired into make verify.

Additional related constraint: existing Rust/Go fixture tests assume methods ending in .REQ / .RSP are hypergraph request/response payloads. Prophet evidence.v1 payloads are not HGRequest/HGResponse, so they need a separate fixture test path or generalized typed-payload handling before being added to the ordinary fixture set.