Never roll back an ambiguous broadcast as if it had been refused (B-76, TX-04, TX-05, TX-20, TX-21, BET-16, BET-17, BET-23, WDR-11, WDR-12, WDR-16, API-13)

place_bet and request_withdrawal released everything on any exception from the
broadcast, including the 15s timeout and a connection dropped after the write. The
tx may have propagated: a bet's sats landed in the pool with no participant, a
withdrawal left while its row said failed and its coins were spendable again.

- client: ElectrumRpcError (subclass of ElectrumError) is raised only for a reply
  carrying a JSON-RPC `error`; timeouts, drops and write errors stay plain
  ElectrumError.
- tx/outcome.py:broadcast_with_verdict sorts a broadcast into accepted / refused /
  uncertain. A refusal is verified first: ElectrumListener.transaction_known asks
  blockchain.transaction.get of the active server and every other one (10s each) —
  any server returning the tx means accepted; the active server plus
  MIN_QUORUM_RESPONSES others all denying it means refused (ALLOW_NO_QUORUM keeps
  the reduced rule); too few answers is uncertain. "already known" wording is only a
  shortcut that skips the check. With no network to ask, a refusal is uncertain.
- place_bet / request_withdrawal / _trigger_payout use it: only a verified refusal
  releases; uncertain leaves the rows building for the reconciler, publishes SSE and
  POST /bets and POST /withdrawals answer 202 with status building; "already known"
  promotes a payout (payout_sent) like any accepted broadcast.
- An accepted transaction is fanned out to every other server
  (ElectrumListener.fan_out_transaction, best effort, off the caller's path). The RBF
  replacement in bump_fee is left for B-77, which rewrites that function.

Tests changed because the spec changed: the existing "refused broadcast" tests raised
a bare RuntimeError (now an uncertain outcome) and are made explicit refusals
(rpc_error) with a network that denies the tx; direct route calls pass a Response;
FakePayoutListener gains the network surface.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

app/rounds/scheduler.py

@@ -17,6 +17,7 @@ from app.rounds.config import get_round_config
 from app.rounds.draw import draw_winner, header_hex_to_block_hash
 from app.rounds.events import broadcaster
 from app.rounds.service import open_new_round_if_needed, round_deadline, winner_share
+from app.tx.outcome import BroadcastOutcome, broadcast_with_verdict
 from app.wallet.hd import derive_round_pool_key
 from app.wallet.plm_network import PLM_MAINNET
 from app.wallet.psbt_builder import InsufficientFundsError, Utxo, build_payout_transaction
@@ -496,13 +497,14 @@ class RoundScheduler:
             pending_id = pending.id
 
         # --- Phase 4: broadcast, then promote the pending row --------------------
-        try:
-            await client.broadcast(built.raw_hex)
-        except Exception:
-            # The row stays "building": the reconciler will ask the chain about it
-            # and, finding nothing, abandon it and clear payout_txid (B-25) — instead
-            # of the round being stuck with a payout_txid that never went anywhere.
-            logger.exception("round %s payout broadcast failed", round_id)
+        # B-76 (TX-05): the same three outcomes as a bet's broadcast. Accepted — the
+        # server took it, or refused with "already known" / a server of the network
+        # holds it — promotes the row; a refusal and an uncertain outcome both leave it
+        # "building" with a payout_failed entry, since which of the two it really was
+        # is the reconciler's call, made against the chain (TX-16, TX-17).
+        verdict = await broadcast_with_verdict(client, self._listener, built.raw_hex, built.txid)
+        if verdict.outcome is not BroadcastOutcome.ACCEPTED:
+            logger.error("round %s payout broadcast not accepted (%s): %s", round_id, verdict.outcome.value, verdict.reason)
             await self._log_payout_failure(round_id, winner_user_id, "broadcast rejected")
             return