Swap interim hand-written RuleSpec module for the upstream encoder version (pin + provenance in verification strip)

What

Once the encoder-produced module for 7 U.S.C. 2013(a)(2) merges upstream (TheAxiomFoundation/rulespec-us#781, gated on TheAxiomFoundation/axiom-corpus#292), replace the hand-written interim module at public/rulespec/us/statutes/7/2013/a/2.yaml with the upstream version:

1. Vendor the upstream YAML via a pinned fetch — record (module id, rulespec-us ref, content sha256) and verify in CI rather than hand-copying (reusable check tracked in TheAxiomFoundation/axiom-rules-engine#98).
2. Keep the WASM oracle tests in src/lib/costShareAxiom.test.ts unchanged — they encode published FY2025 assignments and boundary semantics, and must pass identically against the upstream module (rule names may need remapping in src/lib/costShareAxiom.ts if the encoder names differ).
3. Update the in-app verification strip to surface provenance, not just execution: module id + pinned rulespec-us ref/sha alongside the engine version.
4. Apply the same treatment to the vendored 7 CFR 275.23(d)(2) module used by /qc-liability.

Why

The interim module is behavior-verified but hand-written with sha256:local proof atoms — no corpus grounding or encoder provenance. The strip currently attests execution ("recomputed by the Axiom rules engine") without distinguishing grounded provenance; after the swap it should attest both.

Start with public/rulespec/us/statutes/7/2013/a/2.yaml, src/lib/costShareAxiom.ts, src/lib/costShareAxiom.test.ts, and the in-app verification strip. Check the upstream rulespec-us and axiom-corpus dependencies before changing the vendored modules, and review axiom-rules-engine#98 for the reusable verification approach. Done means both specified modules have pinned provenance verified in CI, the oracle tests remain passing, and the strip shows module and rulespec provenance alongside the engine version.