chore: deploy boring-tx-state-machine support — remove compat shim dependency

[whoabuddy]

Context

The boring-tx-state-machine rollout deployed the relay (v1.27.2) and landing-page (v1.37.1) on Apr 3, 2026. x402-api-host is still on v1.6.1 and running entirely through the compat shim.

Blocked by: aibtcdev/x402-sponsor-relay#301 (frontier drift fix) — deploy relay fix first, then this.

Current state

Every payment event from x402-api-host shows:

• compat_shim_used: true — relay compat layer inferring status
• paymentId: null — old code doesn't generate paymentIds
• checkStatusUrl_present: false — no canonical polling available
• terminalReason: sender_nonce_duplicate — correctly inferred via compat, but fragile

The compat shim is working — it infers sender_nonce_duplicate from the old conflicting_nonce error and produces structured lifecycle events (payment.fallback_used → payment.retry_decision → payment.finalized). But it's a bridge, not a destination.

What's needed

Deploy the version that:

1. Generates paymentId on payment initiation
2. Uses checkStatusUrl from relay responses for canonical status polling
3. Emits native payment.* lifecycle events without compat inference

This should align with what landing-page v1.37.1 already does.

Evidence from logs (Apr 4, 2026)

• 44 errors: all Payment settlement failed / conflicting_nonce (automated test client)
• 132 warns: 44x each of payment.fallback_used, payment.retry_decision, payment.finalized — all compat path
• Errors should decrease once relay #301 is deployed (nonce gaps self-heal)

Would also close

• Retry settlement on conflicting_nonce with backoff #84 (retry settlement on conflicting_nonce) — boring-tx handles retries with payment.retry_decision
• stx402.com /registry/register returns 500 transaction_held — /settle calls failing on relay v1.27.1 #93 (500 on /settle) — structured terminal reasons replace opaque 500s

Priority

High — next in rollout sequence after relay #301.

🤖 Generated with Claude Code