dash: T1c byte-parity KAT vs live p2pool-dash oracle corpus (share-v16) [do-not-merge]

[frstrtr]

T1c byte-parity — the last gate before ★M1 JOIN

Closes the serialization-parity gap the 2026-07-21 join-lane audit flagged:
test_dash_conformance.cpp only exercised synthetic / out-of-band vectors —
there was no byte-parity test against a real p2pool-dash node. This adds one.

What

• test/data/dash_oracle_corpus.hpp — 29 distinct canonical shares captured
  off a controlled p2pool-dash node JOINED to the live public sharechain
  (share-v16 / min-proto-1700) via the oracle-gate on VM210. Each raw wire entry
  [VarInt type=16][VarStr contents] was cross-validated byte-identical across
  4 independent peers, deduped by share_hash.
• test/test_dash_oracle_byte_parity.cpp — for every canonical SHARE_RAW:
  round-trips it through the production load_share → DashFormatter::Read →
  DashFormatter::Write path and asserts serialize(parse(raw)) == raw — the
  exact condition for a c2pool-relayed share to VERIFY_PASS on the fork — plus
  semantic cross-checks (prev_hash / donation / new_tx_count /
  pubkey_hash → payout_script) against the fork's independently-parsed
  SHARE_RECV fields.

Result

• 30/30 tests pass. c2pool's DASH v16 wire layout already byte-matches the
  canonical p2pool-dash fork — zero serialization divergences found. The gap
  was test coverage (synthetic vectors), now closed with the real captured corpus.

Live corroboration (out-of-band, not in this PR)

A c2pool-dash --run --connect <oracle>:8999 node was accepted as a peer by the
canonical fork (Incoming connection ... p2pool version: 1700 'c2pool', peers
4→5), downloaded the full live sharechain and parsed every share with 0 parse
failures / 0 VERIFY_FAIL, and disconnected cleanly — 0 VERIFY_DIFF / 0 NOBAN
logged by the oracle. The offline round-trip KAT here pins that parity as a
repeatable gate with no live dependency.

Not yet exercised

The c2pool mints a fresh share → oracle byte-VERIFY_PASSes it leg needs a
stratum miner + coin RPC on the joined chain (the mint-and-relay step); the
connect-only download node above does not produce shares. Serialization parity
(what determines the byte-diff outcome) is proven both offline and by clean
full-chain parse.

do-not-merge — integrator reviews + merges.

[frstrtr]

This should go green on a rebase now — #918 landed the mechanism fix.

This PR has been red since 07-25 for a reason that had nothing to do with its content. The two failing legs report:

1361 - */DashOracleByteParity.RoundTripsCanonicalWireBytes/*  (Not Run)
1362 - DashOracleByteParityCorpus.IsPresentAndNonTrivial       (Not Run)

"Not Run" was never a test failure — it was gtest_add_tests(... AUTO) registering cases from a source scan whether or not the binary was ever built. ctest then reported them Not Run and exited 8.

#918 (merged c4778efe) replaces that with gtest_discover_tests(... DISCOVERY_MODE PRE_TEST), which queries the actual binary at test time. A case that was not built no longer gets registered, so it skips honestly instead of failing.

Verified: this branch was last updated 2026-07-25T11:28Z and does not contain c4778efe. It is running against the old registration mechanism.

Action

Rebase onto master and re-run. If test_dash_oracle_byte_parity still is not built after that, the remaining fix is the one #895 describes — add the target to the build.yml --target lists for both Linux x86_64 and the ASan job, mirroring dgb_g1_oracle_byte_parity_test and bch_g1_oracle_byte_parity_test.

Why this PR matters more than its red status suggests

It carries the T1c corpus: 29 canonical shares captured off a live p2pool-dash node joined to the public sharechain, each cross-validated byte-identical across 4 independent peers, asserting serialize(parse(raw)) == raw.

That is our only real evidence of wire-format parity with canonical p2pool — and it has been sitting unmerged and unrun for two days over a CI registration mechanism. Landing it converts byte-parity from a local claim into a CI-enforced gate.

Worth stating plainly: I predicted this would go green the moment #918 merged. It did not, because CI results do not retroactively apply to a branch that predates the fix. The rebase is the missing step.