Count pending send reservations when branch spend is present

[kojibai]

Motivation

• Prevent available Φ from being overstated when a payload's branchSpentPhi is non-zero but the local ledger contains newer pending send reservations (e.g., from another tab), which can allow accidental over-exhale.
• Ensure pending send reservations are counted even when branchSpentPhi causes the ledger check to narrow to note kind only.

Description

• Added a new helper getPendingReservedScaledForKind in src/utils/sendLedger.ts to sum pending (unconfirmed) reservations by kind.
• Updated the availability/reservation logic to include pending send reservations when branchSpentScaled > 0n by combining getReservedScaledForKind(..., "note") with getPendingReservedScaledForKind(..., "send") in src/pages/SigilPage/useSigilSend.ts.
• Applied the same reservation calculation change in the UI/summary paths: src/pages/SigilPage/SigilPage.tsx and src/components/VerifierStamper/VerifierStamper.tsx, and updated the corresponding imports to include the new helper.
• Changes are limited to computing ledger reserved amounts and imports, and do not alter storage formats or cross-tab messaging semantics.

Testing

• No automated tests were executed as part of this change.

---

Codex Task

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
phi-network-5aii	Ready	Preview, Comment	Jan 31, 2026 7:57pm

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 72474cd494

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid double-counting pending sends with branchSpentPhi

When branchSpentScaled > 0n, this now adds pending send reservations from the ledger on top of branchSpentPhi. In this component, send() already increments branchSpentPhi immediately (before confirmation), and the same transfer is still pending in the ledger until it’s received. In that common case (after a send in the same tab, before receive), the amount is subtracted twice, understating remaining Φ and potentially blocking valid sends. Consider only adding pending sends that aren’t already reflected in branchSpentPhi, or switching to confirmed-only ledger amounts when branchSpentPhi is maintained in-memory.

Useful? React with 👍 / 👎.