L-TRI-3 Week 2: integrate V2 SHA256 response into POST /prove + Solana

[gHashTag]

Context

L-TRI-3 Week 1 (commit cf951b2c) landed the V2 phi-challenge module: 16×16 GF(2^4) matmul with CHAMPION_WEIGHTS, SHA256 response packing, and 8 adversarial unit tests. The module is in cli/tri/src/depin/phi_challenge.rs alongside V1.

Week 2 wires V2 into the live entry points without breaking V1 clients.

Scope

Rust (cli/tri):

• Add version: u8 field to ProveRequest (default 1).
• Branch on version in post_prove: V1 keeps 4-byte gf16_dot4 path; V2 takes 32-byte SHA256 response, verified via verify_phi_response_v2.
• KAT test with pinned (epoch, node_id) → exact 32-byte response.
• HTTP integration test for v2 valid + invalid (mismatch + wrong length) paths.

Solana (contrib/solana/programs/tri-mining):

• New instruction submit_proof_v2(phi_response: [u8; 32], merkle_root, signature).
• On-chain V2 verification: derive 16×16 challenge from SHA256, run GF(2^4) matmul against CHAMPION_WEIGHTS, SHA256 the packed product, constant-time compare.
• Keep existing submit_proof (V1) untouched for backcompat.
• Update Anchor test (contrib/solana/tests/tri-mining.ts) with parallel V2 path.

Out of scope

• No changes to FPGA, dlc10, Vivado workflows.
• No master ↔ main reconciliation.

Compliance

• L1: every commit has Closes #<this issue>.
• L7: Rust-only, no new .sh / .py.
• No unsafe. No production unwrap().

Cites prior work: L-TRI-1 643892c6, L-TRI-2 0fa1cb7f, L-TRI-3 W1 cf951b2c.