reservations-epic: update m1/keep-core-client for tbtc-v2 PR #1116's stabilized router ABI (selector split + walletReservations removal)

[piotr-roslaniec]

Context

tbtc-v2 PR #1116 (chore(bridge): milestone-1 UTXO reservations stack tracker, threshold-network/tbtc-v2#1116) stabilizes the Solidity-side ABI for the m1 reservations feature. keep-core#4274 (m1/keep-core-client, already merged into reservations-epic) was generated against an earlier draft of that ABI. Two confirmed deltas require a keep-core-side follow-up before mainnet activation; both directions were decided by the repo owner (keep the new, cleaner tbtc-v2 shape, adapt keep-core rather than reverting the Solidity side).

1. Router selector reshaping

• submitReservationProof(uint8 proofType, ...) (the single dispatcher keep-core#4274's pkg/maintainer/spv package calls via submitReservationActionProof/SubmitReservationAcceptanceProof/SubmitReservationReanchorProof) no longer exists at the Bridge address. It has been split into two typed selectors: submitReservationAcceptanceProof(txInfo, proof, reservationKey, requestNonce) and submitReservationReanchorProof(txInfo, proof, reservationKey, requestNonce) (no proofType/mainUtxo args).
• notifyReservationActionTimeout(uint256 reservationKey, uint32[] walletMembersIDs) dropped the walletMembersIDs argument; the tbtc-v2 signature is now notifyReservationActionTimeout(uint256 reservationKey).

Needed: regenerate keep-core's ReservationRouter ABI bindings (pkg/chain/ethereum/tbtc/gen/**) against the new tbtc-v2 ABI, then update the call sites in pkg/chain/ethereum/tbtc.go and pkg/maintainer/spv/reservation_acceptance_proof.go / reservation_reanchor_proof.go / reservation_action_timeout_watch.go to call the new typed selectors directly (dropping the proofType/mainUtxo plumbing) and drop the walletMembersIDs argument from the timeout-notification call site.

2. walletReservations enumeration view

• ReservationRouter.walletReservations(bytes20 walletPubKeyHash) returns (uint256[]) (full per-wallet reservation-key enumeration) does not exist on the current tbtc-v2 ABI; this was a deliberate storage-cleanup decision (see tbtc-v2 commit 4d549e64, BridgeState.sol __gap resize 48->39), not an oversight to be reverted. keep-core#4274's TbtcChain.WalletReservations() (in pkg/chain/ethereum/tbtc.go) and its callers in pkg/maintainer/spv/pkg/tbtc currently call this removed view.
• walletReservationsCount(bytes20) and walletReservationsAmount(bytes20) (aggregate count/amount per wallet) remain available on the router and are unaffected.

Needed: update keep-core's call sites that currently call WalletReservations(walletPubKeyHash) to stop relying on full on-chain key enumeration. Reconstruct per-wallet reservation-key tracking from the already-emitted reservation lifecycle events (ReservationAcceptanceRequested, ReservationReanchorRequested, action-settlement/timeout events, etc. - keep-core's own indexer/watcher machinery already keys off events elsewhere in this codebase) instead, or confirm walletReservationsCount/walletReservationsAmount are sufficient for the actual use case at each call site and drop the enumeration dependency entirely.

Source

Both deltas were confirmed via direct diff inspection of keep-core PR #4274 (merge commit a7b27fe9) against the current tbtc-v2 reservations-upgrade branch, as part of a multi-agent review of tbtc-v2 PR #1116.

3. reservationActions() return-tuple shape has diverged (bigger than just a new field)

ReservationReservationAction (keep-core#4274's compiled Go binding, pkg/chain/ethereum/tbtc/gen/abi/ReservationRouter.go) expects a 17-field tuple, in this exact order:

type ReservationReservationAction struct {
	TargetWalletPubKeyHash  [20]byte
	RequestedAt             uint32
	TimeoutAt               uint32
	TxMaxFee                uint64
	ActionType              uint8
	State                   uint8
	FeePaid                 bool
	Redeemer                common.Address
	Amount                  uint64
	ActionDataHash          [32]byte
	SourceAnchorUtxoHash    [32]byte
	UsedRetryCredit         bool
	WatchtowerDefaultDelay  uint32
	WatchtowerLevelOneDelay uint32
	WatchtowerLevelTwoDelay uint32
	IsPartial               bool
	RetryCreditSourceNonce  uint64
}

Authoritative current shape (extracted directly from the compiled ABI's tuple components, checked in at solidity/test/fixtures/ReservationAbi.snapshot.json -> structs.ReservationAction, not hand-counted): 20 fields total -- targetWalletPubKeyHash bytes20, requestedAt uint32, timeoutAt uint32, txMaxFee uint64, actionType uint8, state uint8, feePaid bool, redeemer address, actionDataHash bytes32, sourceAnchorUtxoHash bytes32, amount uint64, usedRetryCredit bool, watchtowerDefaultDelay uint32, watchtowerLevelOneDelay uint32, watchtowerLevelTwoDelay uint32, retryCreditSourceNonce uint64, isPartial bool, termSeconds uint32, dissolutionDelay uint32, minAmount uint64. It inserts actionDataHash/sourceAnchorUtxoHash (bytes32) immediately after redeemer -- ahead of amount, not after -- and appends termSeconds, dissolutionDelay, minAmount. From field 9 onward, every position's type diverges from keep-core's expectation.

This is not a cosmetic diff: keep-core#4274's pkg/maintainer/spv maintainer loop calls spvChain.GetReservationAction(reservationKey, requestNonce) (which ABI-decodes this exact tuple) before every proof submission (submitReservationActionProof, both the acceptance and reanchor paths). A tuple-arity mismatch at ABI-decode time will fail that call outright once keep-core's compiled bindings are pointed at the live contract -- this is on the same footing as the selector-split and walletReservations items above, not a lower-priority nice-to-have.

Needed: when regenerating keep-core's bindings per items 1-2 above, regenerate against the tbtc-v2 ABI as of the FINAL, stabilized state of this PR (post all remediation), not an intermediate snapshot -- the struct shape has moved multiple times during this epic's development and needs one final, verified re-generation rather than another patch-around.

[linear]

ENG-764