fix: guard X Layer publisher against stale pending nonce

[chin0312]

Incident and cause

The first scheduler-owned canary after PR #35 returned PublicationError for NVDAx, SPYx, and AAPLx. No new Registry transactions were mined. A read-only check for the production signer showed chain 1952 reporting latest nonce=3320 but pending nonce=3316; both documented X Layer Testnet RPC endpoints returned the same four-nonce regression. The existing latest nonce includes the four confirmed SPY/AAPL vault and policy transactions. The publisher previously trusted the stale pending value when building its transaction.

Fix

The publisher now reads both nonce tags and uses max(latest, pending). Thus an RPC pending value cannot send a transaction with an already-consumed nonce, and a genuinely higher pending nonce is still respected. The existing shared publisher transaction lock remains unchanged; there is no parallel submission path.

Scope

• Only apps/api/valtide_api/publisher.py and its publisher tests change.
• No contract, classifier, model, frontend, manifest, scheduler, or signer changes.
• The existing production signer was independently confirmed as authorized using the sender of a successful prior Railway NVDA publication.
• Production publication is currently paused: AUTO_PUBLISH_ENABLED=false, PUBLISH_ENABLED=false. No canary retry or manual publish was sent while this correction is pending.

Validation

• Publisher tests: 53 passed, including pending-below-latest and pending-above-latest cases
• Full backend: 358 passed
• Quant: 11 passed
• Foundry: 26 passed
• Ruff and compileall: passed

After exact-head CI is green, this small fix must be merged and deployed before re-enabling scheduler publication.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
valtide	Ready	Preview	Oct 6, 2026 7:15pm UTC