fix(relayer): reconnect Redis so account setup is not 503 (WALM-626)

[ducnmm]

Ticket

WALM-626 — https://linear.app/mysten-labs/issue/WALM-626/bug-account-setup-blocked-by-persistent-sponsor-503-rate-limiter
GH #905 — #905

Hotfix onto main. Same patch as #906 (dev); cherry-picked so prod can take only this relayer fix without the rest of dev.

What changed?

• Relayer Redis is now ConnectionManager so a dropped connection reconnects instead of 503-ing /sponsor for the process lifetime.
• Reconnect is bounded (2s connect/response timeout, 2s max delay, 3 retries).
• Missing ConnectInfo on the IP limiters no longer returns that 503. hops=0 shares a 0.0.0.0 bucket and still ignores XFF; hops>0 still reads XFF.

Why is this needed?

Mainnet POST /sponsor returns HTTP 503 Rate limiter temporarily unavailable. The dashboard maps that to “Sponsor service is temporarily unavailable” and blocks account setup. /health stays ok because authenticated write-path limiters fail open.

Scope

Unblock gasless account setup on production relayer.

Out of scope

• Fail-opening the sponsor gas budget
• Dashboard copy
• The rest of dev

How was this tested?

• Unit tests (on the dev cherry-source)
• Integration tests
• End-to-end tests
• Manual testing
• Not applicable

Cherry-pick onto origin/main was clean (types.rs auto-merged).

Commands on the dev branch: cargo test -p memwal-server rate_limit --offline (39 passed, 2 ignored), cargo test -p memwal-server client_ip --offline.

How can the reviewer verify it?

1. Diff vs main is the Redis ConnectionManager switch plus rate_limit_peer_addr.
2. After merge, deploy relayer only. Confirm /health.build.commit is this SHA and POST /sponsor is no longer Rate limiter temporarily unavailable.

Risks and dependencies

A live Redis outage still 503s /sponsor (intentional). First command after a drop can still 503 once.

Author checklist

• This pull request maps to one ticket and one logical outcome.
• I reviewed the complete diff myself.
• I removed unrelated, debug, and temporary changes.
• I ran the relevant tests.
• CI is green.
• The branch is up to date with its target branch.
• I added or updated tests where appropriate.
• I documented any important risk, dependency, rollout, or follow-up.
• I provided clear verification steps.
• The pull request is ready for review and is no longer a Draft.

[HoangDucBach]

Approved!

[harrymove-ctrl]

Heads-up before this gets merged: I think it is now a no-op and can be closed.

This is the cherry-pick of the WALM-626 fix onto main, but main already contains that commit directly — a3d8c38a "fix(relayer): reconnect Redis so account setup is not 503 (WALM-626)" (#906) is an ancestor of both origin/dev and origin/main, so the diff applies nothing new.

Confirmed deployed everywhere, all reporting status: ok:

env	/health.build.commit
prod	0ffbacbb
staging	cbbc9c62
dev	09db12d7

I have closed GH #905 as resolved by this work. Leaving the close of this PR to you in case I have the branch history wrong — but as far as I can tell there is nothing left for it to land.

[ducnmm]

Thanks @harrymove-ctrl — not closing yet.

GitHub still lists a 6-file diff vs main (rate_limit.rs +100/−53 plus Cargo.lock / walrus_seal / security_delete_auth / types). a3d8c38a being on main is right, but this branch's two cherry-picks (400c6f43, e088697d) still show as ahead. I'll treat it as leftover cherry-pick noise only after we confirm that file list is empty against current main.

Leaving it open until then. WALM-626 is already Done.