Seller stalls forever on `[3/4] posting the offer` after an instant-fill `MATCHED`; opened deal never accepted probe — 0 tokens served, escrow stuck

[Pithung]

Environment: dexdo v0.2.1 (pin 846f8e5b, generation 4.0.36), mainnet, Windows x86_64.
Class: seller client hang after an offer fills immediately on placement (no RESTED step).

---

Summary

When I provision a fresh market and start the seller while a resting BUY already sits in the
web order book, the offer is consumed at once:

[3/4] posting the offer
seller_offer_outcome MATCHED
[3/4] ... (25s) seller_match_opened token_contract=f84b881f… gateway=bore.pub:9231
deal_handle=deal-0-f84b881f…-seller
[3/4] ... (4631s)      ← stays on [3/4] for 1h15m+, never reaches [4/4] waiting / serving

A deal is created and funded on-chain, the web side lists it in transaction history, but the
seller CLI never advances past [3/4], so it never serves the buyer's probe and delivers
0 tokens / 0 SHELL.

On-chain state of the stranded deal (exactly, status)

state=probe  active=true  funded=true  opened=true  disputed=false  probe_accepted=false
finalized_owed=0  buyer_locked=7.125  deposit=4.125  probe_tick=1  buyer_bond=2
tokens_final=0  tokens_pending=0
probe_time=1788918327  last_claim_time=1788918327  funded_time=1788918304

• Buyer submitted a probe tick (probe_tick=1) at probe_time, then the stream sat idle;
  probe_accepted=false because the seller never served it.
• Deploy --nonce 9232, price_per_tick=1, max_ticks=5 → counter-party buyer
  note 48a0a3925609065d79ba4ab43434074294506a7f73509cee0c59a22dc10b4c52, fill order_id=259,
  bold 5/5 matched, residual_ticks=0.
• No ESTABLISHED connection to the seller gateway (0.0.0.0:8443) at any later check —
  the buyer is not streaming; only the lone LISTEN socket and the bore keep-alive remain.

Contrast with the normal path

scenario	outcome seen
offer rests, buyer matches later (RESTED)	RESTED → seller_ready → [3/4] offer posted → [4/4] waiting for a buyer ✅
offer consumed instantly by resting buy (MATCHED)	MATCHED → seller_match_opened, then pinned at [3/4] posting the offer forever ❌

Every previous successful fill on my side was the RESTED path. This is the first
MATCHED-on-place, and it is the first one that froze.

Suspected trigger: chain getter throttling on the post-match confirm path

A prior run (offer 221, same day) showed the seller's periodic deadline re-read being
throttled by replay protection:

ERROR dexdo::seller::liveness: consecutive authoritative deadline re-reads failed;
 the seller still owns the offer but its current expiry is unverified
event="seller_offer_expiry_read_blind"
error=mainnet contract: run_tvm getter getStats: … exit code: 52 (Replay protection exception). Try again.
consecutive_failures=2  elapsed_since_last_successful_read_ms=9707  attempt_total=563

mainnet.manifest.json sets "requests_per_second": 3. The seller polls very aggressively
and collides with the node's replay-protection on frequent getter calls. My hypothesis is that
the instant-fill path needs the seller to re-read/confirm offer placement and outcome on-chain,
and those calls keep hitting exit-52 throttling, so the CLI spins forever on [3/4] instead of
transitioning to the serving stage.

Impact

• 0 model tokens served, 0 SHELL earned on a deal the web already counts as "done".
• Buyer escrow 7.125 + seller bond 2 stay locked in the TC (opened=true).
• Risk of a new orphaned-opened-deal class (like the Cannot close OPEN deal after TC address recycled — prior StreamStopped beneficiary mismatch #147/Seller deal stuck #148/dexdo close refuses the stop path its own status recommends: INTERNAL / internal invariant failed on an incompatible prior ProbeBurned receipt #152 recycling case):
  if the operator stops the seller while the deal is still opened, nobody can collect until
  either side can sellerStop/recover.

Requests

1. Why does the MATCHED-on-place path pin on [3/4]? Is the post-match confirm step expected
   to complete asynchronously, and what is it waiting for?
2. Please add backoff/retry (or EXIT_CODE_52 handling) to the post-match confirmation getter
   loop so a transient replay-protection rejection cannot stall the whole run.
3. For the already-stranded deal: confirm the intended cleanup — seller-side close
   (sellerStop) on probe/opened, then destroy, versus waiting for the probe window to
   lapse so destroy clears bonds/refund.

Reproduction steps

1. Have a resting BUY for Qwen3.6-27B at 1 SHELL/tick × 5 in the web order book.
2. provision with a fresh nonce and dexdo seller against that market.
3. Observe seller_offer_outcome MATCHED → seller_match_opened, then [3/4] posting the offer
   never exits (reproduced 4631 s and counting).

Happy to provide raw terminal captures, full --data-dir state, or run with RUST_LOG on the
repro if that helps.