fix(InventoryClient): guard zero allocation denominator in determineRefundChainId

[droplet-rl]

determineRefundChainId() divides the per-chain post-relay balance by the cumulative virtual balance with no zero check. A token enabled in tokenConfig but holding no virtual balance on any chain, with no upcoming refunds, makes that denominator zero, and ethers BigNumber.div throws division-by-zero.

Nothing catches it between determineRefundChainId and checkForUnfilledDepositsAndFill, so the throw reaches index.ts and the process exits. Repayment resolution runs before the balance check in evaluateFill, so a deposit the relayer could never fill still reaches this path — the reachable case is a token configured before it is funded, e.g. a fresh deployment or a newly added token/chain.

Treat a zero denominator as zero allocation, matching the existing checks in getCurrentAllocationPct() and getChainDistribution(). Candidate chains then read as unallocated and the deposit is skipped downstream on the existing hasBalanceForFill check, which records a token shortfall for the rebalancer instead of crashing.

Test added to InventoryClient.RefundChain.ts covering a zero cumulative balance. No doc change — behaviour is unchanged whenever the denominator is non-zero.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-08-31T09:52:53.030367Z	158f600	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[droplet-rl]

The comment that triggered me was the review-summary placeholder in its 🔄 Running state, so there was no feedback to act on yet. I waited for the review to finish rather than replying to an empty status table.

It has since completed on 158f600 with no findings — no review body, no inline comments, and the bot left the 👍 reaction it uses to signal "all reviews finished with no findings." So there is nothing to address and I've pushed no new commits; HEAD stays at 158f600.

Since I had the branch checked out, I re-verified the change locally rather than just taking CI's word for it:

• test/InventoryClient.RefundChain.ts — 44/44 passing, including the new zero-denominator case
• tsc --noEmit — clean
• Prettier + ESLint on both changed files — clean
• All 7 CI checks green (install, lint, test, typecheck, dependency-review, both Socket jobs)

One note on the substance, for a human reviewer: the guard is not a novel pattern. getCurrentAllocationPct() (src/clients/InventoryClient.ts:397) and getChainDistribution() (:358) already short-circuit on cumulativeBalance.eq(bnZero) before their .div(). determineRefundChainId was the one allocation path that divided by a cumulative balance without that check. With the guard, a zero denominator yields expectedPostRelayAllocation = 0, which is lte(effectiveTargetPct), so candidate chains read as underallocated and are returned — the deposit is then skipped downstream on the existing hasBalanceForFill check, recording a token shortfall for the rebalancer instead of throwing division-by-zero up through checkForUnfilledDepositsAndFill and exiting the process. Behaviour is identical whenever the denominator is non-zero.

This was the one automated review round allowed on this PR, and it came back clean, so I'm not re-triggering it. If anyone wants deeper scrutiny of the downstream-skip reasoning — that's the part where a human eye is most useful, since it's a behavioural claim rather than a mechanical one — assign me to the PR and I can iterate further.

[droplet-rl]

🔎 View trace