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>

BUGS.md

@@ -137,24 +137,6 @@ the intermediate headers (`blockchain.block.headers`) and validate the chain; on
 linkage mismatch walk back up to 10 headers to find the fork point and follow the
 reorg instead of ending the session (reorg handling: B-85).
 
-### B-76 — An ambiguous broadcast is rolled back as if refused
-
-`place_bet`/`request_withdrawal` release everything on *any* broadcast exception,
-including the 15s timeout and a drop after the write. The tx may have propagated: the
-bet's sats land in the pool with no participant, the withdrawal leaves while its row
-says `failed`.
-
-Fix: only an explicit JSON-RPC rejection can release, and only after verifying it:
-`blockchain.transaction.get(txid)` is asked of the active server and every fallback
-(10s each). Any server returning the tx → accepted; every responder denying it, with
-the active server and the quorum minimum among them → released; too few answers →
-uncertain (below). Matching "already known / already in mempool" messages is only a
-shortcut that skips the check, so an unrecognised message can never release a tx
-that is on the network (spec: TX-04). A timeout or disconnect leaves the rows
-`building` for the reconciler and the API answers 202 with the row in `building`.
-After the active server accepts, the raw tx is also sent to every fallback
-(best effort).
-
 ### B-77 — Only the latest txid is tracked, and `bump_fee` broadcasts before it persists
 
 The poller and the reconciler match `current_txid` only (`replaced_by_txid` keeps