fix(storage): renumber schema versions to 38/34 after an exact collision on main (#2766)

`main` landed Spring AOP (#2416) with SCHEMA_BUMP 37 and
INCREMENTAL_SCHEMA_VERSION 33 — exactly the numbers this branch already used.
Every prior instance in this series was a near-miss, where main took a number
below or beside this branch's. This one is an exact clash: two incompatible
schemas both claiming 37/33, so an index built by either would satisfy the
other's freshness check while carrying content it cannot read.

Renumbered to 38/34 and merged both changelog notes rather than replacing
main's. Extended the reuse-gate test so v33 is asserted to FAIL the gate — a
v33 index carries receiver chains in wire format v1, which the v2 decoder
refuses by design, and an incremental top-up would silently fall back to the
text cascade for every chain-carrying site.

Re-verified after the rebase, not before: 4424 tests and all eight CI benches
green against the new base.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

gitnexus/test/unit/call-summary-schema-version.test.ts

@@ -218,7 +218,12 @@ describe('CALL_SUMMARY incremental reuse gate (U-C5)', () => {
     // A pre-v33 (v32) index predates the Spring AOP Interface→CodeElement
     // relation pair (#2416), so it cannot persist all evidence edges.
     expect(passesReuseGate(32)).toBe(false);
+    // A pre-v34 (v33) index carries `receiverChain` strings in wire format v1,
+    // which the v2 decoder refuses by design (#2766) — an incremental top-up
+    // would silently fall back to the text cascade for every chain-carrying
+    // site → must NOT reuse.
+    expect(passesReuseGate(33)).toBe(false);
     // The current stamp passes the gate (incremental top-up eligible).
-    expect(passesReuseGate(33)).toBe(true);
+    expect(passesReuseGate(34)).toBe(true);
   });
 });