feat: refresh balance allowance cache after order approvals settle

[cesarenaldi]

Summary

• Cherry-picks updateBalanceAllowance() from main (0281f46) into this branch so the action is available
• Wires it into ensureOrderApproval() in prepare.ts — called after handle.wait() confirms the approval transaction settled
• Refreshes COLLATERAL for buy orders; CONDITIONAL (with tokenId) for sell orders
• No-ops entirely when existing allowance is already sufficient (early return path is unchanged)

Test plan

• Verify typecheck passes: pnpm typecheck
• Verify lint passes: pnpm lint
• Manual: place an order from a wallet with no prior approval and confirm the cache refresh fires after the approval tx confirms

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches the order-approval workflow and post-transaction behavior; a wrong asset type/tokenId mapping or extra network call could cause stale allowance handling or minor latency during order preparation.

Overview
Ensures allowance state is refreshed immediately after an order approval transaction settles by calling updateBalanceAllowance() after handle.wait() in ensureOrderApproval().

The refresh targets collateral for buy-side approvals and conditional tokens (including tokenId) for sell-side approvals, without changing the early-return path when allowance is already sufficient.

^{Reviewed by Cursor Bugbot for commit 2096d00. Bugbot is set up for automated code reviews on this repo. Configure here.}

[linear]

DEV-32 Investigate wallet and signer ownership validation in authenticateWith

Investigate whether the Unified TypeScript SDK can verify wallet and signer ownership mismatches during the authenticateWith workflow runner.

This work should cover:

• evaluating whether the SDK can detect cases where signer !== wallet and the signer is not actually an owner of the wallet
• identifying what ownership guarantees are available for the supported wallet types in authenticated flows
• deciding whether mismatch detection can happen proactively during authenticateWith or only surface indirectly through downstream auth failures
• clarifying how this should behave for EOAs, proxy wallets, Safe-based flows, and any other supported wallet models
• documenting the result and any limits of what the SDK can or cannot verify

Context:
When signer and wallet differ, authentication semantics depend on the signer being authorized for the target wallet. This should be investigated explicitly so the SDK does not imply stronger guarantees than it can actually enforce.

Outcome target:
Make a clear SDK decision on whether wallet/signer ownership mismatch can be validated during authenticateWith, and define the expected behavior if it can or cannot.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b4f0997. Configure here.}