Fix monitor persistence and cross-chain receipt finality

[fengjy73]

What changed

• upgrades legacy Mychain SDP and PTC Hub contracts in place before deploying the monitor stack
• packages the matching runtime bytecode and keeps the existing storage layout intact
• normalizes persisted multi-VM JSON contract addresses before wiring Monitor/SDP/PTC contracts
• persists Monitor and Monitor Verifier identities in the BBC context so plugin restarts recover the same contracts
• preserves PTC/Monitor addresses and the complete merged blockchain metadata during partial configuration updates
• backports lane-aware anchor_process uniqueness, including an idempotent production upgrade script
• adds a finite gRPC deadline to target-chain receipt reads
• fixes Dioxide and Dioxide2 receipt evaluation so an archived relay group with a failed embedded invocation is terminal instead of remaining pending
• accepts Dioxide State=DUS_FINALIZED/DUS_ARCHIVED as durable finality when final relay transactions omit ConfirmState
• adds Mychain monitor application-flow tooling, fixtures, and regression tests
• routes monitored SDP V1/V2/V3 requests and acknowledgements symmetrically through Monitor on Ethereum, FISCO BCOS, and Mychain
• replaces compiler-sensitive reverse-padded byte decoding so non-word-aligned business payloads survive Ethereum, FISCO solc, and MySolidity unchanged
• preserves the populated FISCO MonitorVerifier when replacing a legacy Monitor, retaining TPBTA monitor-node endorsements
• skips TPBTA-on-target synchronization for V0 receivers that have no configured PTC Hub, while retaining the source-BTA check for PTC-capable targets
• persists confirmed SDP terminal results by the already-known pool row ID instead of relying on a plugin-native transaction hash as the update key
• adds credential-free live-check tools for version matrices, system bindings, receipts, and exact receiver payloads

Root causes

Legacy Mychain deployments predated the monitor-aware SDP/PTC implementations. Relayer also persists some Mychain addresses as JSON envelopes; hashing the complete envelope produced non-existent contract identities. The generated Monitor Verifier name and updated client configuration were not persisted after setup, so restart recovery could silently lose regulatory wiring.

The regulatory branch also predates two generic Relayer fixes already merged upstream: persisting the merged BlockchainMeta on a partial update and including tpbta_lane_key in anchor progress uniqueness. Both are backported here because losing either state can break monitor/PTC recovery on this branch.

Receipt queries had two independent finality defects: the Relayer-to-plugin gRPC call had no deadline, and the Dioxide plugins treated every missing next-hop relay as transient. An archived relay group can have no next hop because an embedded invocation already failed; that state is terminal and must be reported.

The monitor envelope used reverse 32-byte chunks followed by a length word. The previous assembly decoder depended on compiler-specific memory alignment: target receipts could succeed while a 36-byte business payload was truncated and zero padded. The replacement decoder computes the legacy codec boundaries explicitly and copies logical bytes without assembly.

FISCO monitor replacement initially deployed an empty MonitorVerifier and repointed the existing PTC Hub. Existing monitor-node endorsements live in the old verifier and are populated when a TPBTA is added, so the new verifier rejected every regulated target call with no monitor node endorse info. The upgrade now reuses the verifier already bound to the current PTC Hub.

The corrected source-BTA test exposed a second compatibility boundary: Dioxide is a V0 BBC target with no PTC Hub, so calling its V1 hasTpBta interface blocked an otherwise valid Ethereum-to-Dioxide V1 message after regulatory approval. Relayer now reads the receiving BBC context and only uploads TPBTA when the target actually exposes a configured PTC contract.

After the Dioxide submissions became reachable, receipt confirmation exposed a terminal-state persistence bug. The confirm worker already owns the sdp_msg_pool row ID, but the old code updated by the transaction hash returned by the plugin. Dioxide's native non-hex hash path left the row pending, causing duplicate execution reports. Confirmed results now update by primary key while retaining the native hash as evidence.

One more Dioxide response-shape mismatch remained after persistence was fixed. Final relay transactions can expose only State=DUS_ARCHIVED and omit ConfirmState; the plugin treated those durable transactions as unknown forever. Both Dioxide implementations now use either confirmed-transaction state or durable block state, while invalid/forked/archived-uncle states are terminal failures. A node-level transaction not found remains an error and is isolated to its own confirmation item rather than blocking a healthy item in the same batch.

Validation

• Mychain context, Monitor, PTC and SDP suites: 37 tests passed on Java 8
• Relayer blockchain metadata regression test: 1 test passed on Java 8
• Dioxide and Dioxide2 finality suites: 7 tests each on Java 21
• FISCO BCOS Monitor V1/V2/V3 compatibility suite passed; the legacy FISCO module also compiles with the regenerated Monitor V3 wrapper
• Relayer V0-target compatibility and confirmed-result identity tests passed together with the existing blockchain-manager regression suite on Java 8
• production Mychain setup survived restart with exact SDP/Monitor/Verifier/PTC wiring
• production FISCO reports Monitor V5 with matching SDP/PTC/MonitorVerifier bindings; normal and monitored FISCO -> Ethereum V1/V2/V3 messages reached successful target receipts, and the Ethereum receiver retained the full monitored V3 payload byte for byte
• post-fix monitored Ethereum -> FISCO V1/V2/V3 UCPs 981a7490...05c98, e31135e2...54172, and ac3c38e6...7b102 all reached SUCCESS, regulation TARGET_EXECUTED, and exact receiver payload recovery
• post-deployment Ethereum -> Dioxide V1 ordinary UCP 5d055175...a1a7 changed from an incorrect unknown/pending receipt to SUCCESS, tx_success, and regulator TARGET_EXECUTED success=true when the archived-state fix was loaded
• fresh monitored Ethereum -> Dioxide V1 UCP 148af653...fe73d reached target transaction 42csksb2...cd5mg, PTC weight 100%, regulation APPROVED/TARGET_EXECUTED, and all four completeness flags; its Dioxide relay group was DUS_ARCHIVED/TXN_ARCHIVED, both embedded invocations succeeded, and the receiver payload decoded exactly to eth-to-diox-statefix-regulated-1787692602-sdp-v1
• public Data API and regulatory platform recorded complete four-stage reporting for all three live directions:
  • Mychain my02 -> Dioxide diox04: UCP 402c5099b2bb0a24dad6de5968362abc8884657abcbd798eb30eaede2fb66266
  • Dioxide diox04 -> Ethereum eth04: UCP 7df31f8e109259f25baed08cfaf4b86c22d85d1462557902d1fe19de69a210b1
  • Ethereum eth04 -> Dioxide diox04: UCP 0503484006a919b03555cda37bbc6a97fbd38c95d51035a657fe589c6d9af832
• each live case reached target-chain success, PTC approval weight 100%, regulation APPROVED, TARGET_EXECUTED, and all four completeness flags true

The full reactor build still depends on private GitHub Packages snapshots; targeted tests were compiled and run against the production-compatible dependency set.