Add megapool exit & claim lifecycle UI (follow-up to #154)

[saju01]

Megapool exit & claim lifecycle (follow-up to #154)

This adds the exit + claim/withdraw half of the megapool lifecycle, so node operators can manage validators after deposit — not just create them.

⚠️ Stacked on #154 — review only the last commit

This branch is built on top of #154's deposit branch, so it shares those commits. The only new commit here is b38de52 ("Add megapool exit & claim lifecycle to UI", +409 lines / 8 files). Everything else is #154. Intended sequencing: merge #154 first, then this. Kept separate on purpose so the deposit UI can land independently and operators get both options.

The new commit only adds files/handlers — it does not modify the deposit logic.

What's added

🚪 Exit (state-aware — UI picks the right path per validator state):

• exit-queue (by validatorIndex) — exit a validator still in the entry queue, before it stakes
• exit-validator (by validatorId) — beacon voluntary exit for an active validator
• notify-validator-exit (by validatorId) — notify the protocol of the exit

💰 Claim / withdraw:

• pending-rewards — surfaces claimable node rewards in the UI
• distribute — claim accrued megapool ETH/rewards to the node
• claim-refund — claim the node's bond/refund back
• read helpers: calculate-rewards, beacon-withdrawal-queue-estimate

How it's wired (mirrors the existing deposit pattern)

• API (build/api/src/index.ts): 13 new megapool ... action handlers. executeCommand now waits on the txHash for the 4 actions that broadcast a transaction (exit-queue, notify-validator-exit, distribute, claim-refund). exit-validator is a beacon voluntary exit and returns no on-chain tx, so it is correctly not waited on.
• UI: AppService methods + 4 new response types (CanExit, CanDistribute, CanClaimRefund, MegapoolRewards) + a new MegapoolActions component (Exit + Claim sections, preflight → execute → wait, TxsLinksBox, MUI), rendered in MinipoolDetails.

Validation — exercised live on Hoodi against a real deployed megapool

Built the v1.20.x daemon and ran it in external-client mode against public Hoodi endpoints. Registered a node and deposited a real 4-ETH megapool validator, then exercised every new route against the live megapool:

• megapool 0x080fc2df40ec100e1a85a8626836b2b01f6a6209, validatorCount 1
• deposit tx: https://hoodi.etherscan.io/tx/0x5f1ef6b396c2a4fa25aae25a347d65c3dcfdb635dca4627273e4c4637517b6de
• pending-rewards ✅ success (clean reward split)
• can-distribute ✅ success (megapoolNotDeployed: false)
• can-claim-refund ✅ success (canClaim: true, real gas estimate ~42k)
• can-exit-validator ✅ success (invalidStatus: true — validator not yet active on beacon, the correct state)

Both API and UI builds pass (tsc clean; UI production build ~180 kB gzip; only a pre-existing Minipools.tsx eslint warning, untouched here).

[saju01]

Six weeks on, so a status ping — and a note that this one now needs a rebase.

main has moved since 24 June and GitHub reports this branch as conflicting (mergeable_state: dirty). Happy to rebase it, but I'd rather not churn the branch if the work isn't wanted in its current shape, so a steer would help:

1. Is the deposit UI direction still what you want? Add stable megapool validator deposit UI #154 covers the deposit flow and this PR builds the exit/claim lifecycle on top. If the megapool UI is being approached differently upstream, I'd sooner know now than rebase 21 files into a design that's been superseded.
2. Anything blocking review? The end-to-end validation on a live Hoodi pool is in Add stable megapool validator deposit UI #154's thread — first-run wallet flow, deposit against real Rocket Pool contracts, and the SMARTNODE_NETWORK remap fix in 065edbf. If there's a further test you'd want before this is reviewable, I'll do it.

No rush on my side, and no problem if the answer is "not now" or "not this way" — I'd just rather close it cleanly than leave it sitting open indefinitely. Let me know either way and I'll act on it.

[saju01]

Rebased onto current main and restacked on top of #154 — now conflict-free (mergeable_state: clean).

Same conflict resolution as #154: main moved to the reusable bump-upstream workflow (#156), which supersedes the inline workflow fix this branch carried. I took main's version, so .github/workflows/auto_check.yml is byte-identical to main and this PR touches no CI.

This PR still stacks on #154 — it adds the exit & claim lifecycle on top of the deposit UI, so #154 should land first.

Re-verified after the rebase:

• UI build passes (react-scripts build)
• API build passes (tsc, no errors)
• rocketpool-start.sh passes bash -n
• workflow file diffs clean against main

Ready for review.