validator: tighten reserve slippage cap to 25% and log slippage_bps

[anderdc]

Summary

• Cap RESERVE_SLIPPAGE_MAX_BPS from 100_000 (1000%) to 2_500 (25%). The old value sat above the 10_000 threshold where quote_within_slippage goes non-positive — anything ≥100% turned the gate into a no-op. A SwapReserveSynapse with slippage_bps=10_000+ could land a quote arbitrarily far from the miner's commitment rate and still pass.
• Add slippage_bps to the SwapReserve REQUEST log line so the next swap-550-shape ticket is diagnosable from logs in a minute, not an afternoon of archive-node probes.
• Flip test_slippage_max_bps_clamp_applied to assert the new behavior (clamp now bites a wildly-off quote) and add an explicit RESERVE_SLIPPAGE_MAX_BPS < 10_000 guard so a future bump can't silently disable the gate again.

Why

Surfaced while diagnosing swap 550 (btc→tao, COMPLETED, destAmount=98M rao vs deliveredAmount=28.2M rao — 71% gap). Chain history showed the miner's commitment was stable at rate=290.87 for ≥1000 blocks before init; the quote could only have settled if the synapse arrived with slippage_bps ≥ 7091. Validator logs from later that day showed the same operator running test traffic with deliberately-mismatched quotes through the same wallet pair (5HjnFE7Z / 5EqNSv84 / miner UID 14). So swap 550 itself is operator test traffic, not real user harm — but the underlying surface (any client can pass slippage_bps=10_000 and disable the rate gate) is a footgun that's worth closing before a non-operator client trips it.

CLI default (--slippage 2.0 → 200 bps) and user --slippage flow are unchanged. The CLI already warns above 10% and clamps to MAX_BPS, so the visible UX change is "explicit --slippage 30 now clamps to 25% instead of 1000%."

Test plan

• pytest tests/test_axon_handlers.py -k slippage — 5/5 passing, including the flipped clamp test
• pytest tests/test_axon_handlers.py tests/test_rate.py — 78/78 passing
• Spot-check on a live validator after deploy: confirm REQUEST received — … slippage_bps=N … shows up and that an explicit --slippage 30 from the CLI now logs as slippage_bps=2500 (clamped) and accepts within the 25% band.