Replace probe dumps with outcome analysis: stack load is fine, mint 5110 /
SKIP_CONFIRM / pendingIncoming with available=0; sparse what-worked table
and pay board example (tsv_ok=2, wallet_wd=14, done=0).
Expand CLI-AUTOMATION-NOTES with the 2026-07-19 max-ladder probe table:
hi descent while lo=0, OK at 424114/822256, fine bisect fails to 822788,
and same-day landing Giga/Mega withdraws for contrast.
Record recurring bank SQL 5110/P0001 as server-side (not mon/wallet),
max-search fail band ~824k GOA, and same-day landing recent_withdraws
that still show Giga/Mega explorer mints succeeded earlier.
UX fix: after bank OK_BANK, available is often still 0 while pendingIncoming
ticks up. The silent wait looked hung. Show OK/OK_BANK withdraws in the order
they started, match wallet txs, and update pendingIncoming→done with a timer
on the same wallet DB. Short run-pending only; default wait 90s.
No host-agent or suite phase loads the path; taler-monitoring.sh
phase alias goa-ladder already runs check_amount_ladder.sh.
Update docs and admin-log pointer comments to the amount ladder only.
Wallet accept/tx dumps mix log lines with JSON; json.loads from the
first brace always failed, and regex only scanned accept (no reservePub).
Parse with JSONDecoder.raw_decode, scrape both files, score by WID/amount.
Prefer Homebrew python for taler-helper-sqlite3; find_wallet_cli prefers
ts-core 1.6.x. Soft-skip max-1 mint 5110/P0001 as ceiling.
Verified on live GOA: mid rungs force-select HTTP 200 + confirm 204 → OK_BANK.
Rename user-facing e2e "ATM withdraw" to "Bank withdraw". The ladder
amounts (20/50/100/200/…) were labeled ATM because they match typical
CHF cash-note sizes (Bankomat), not because anything hits a physical ATM.
Keep E2E_ATM_MAX as alias of E2E_BANK_WITHDRAW_MAX; keep e2e.atm-* group ids.
