fix(frontend): close network-mismatch signing window with a fresh pre-sign check

[Macnelson9]

Closes #927

Summary

useNetworkMismatch polls Freighter's getNetworkDetails() every POLL_INTERVAL_MS (previously 5s) to drive the write-blocking mismatch banner. Because it's a poll and not an event subscription, there's up to one poll interval after a user switches Freighter's active network where isMismatch still reflects the previous state. If a user has a form open, switches Freighter's network for an unrelated reason, and submits within that window, the app could let a transaction reach the signer before the UI gate catches up — undermining the guarantee the mismatch banner (f6e88f3, 901021f) was specifically built to provide.

Investigation: is there a push mechanism?

Checked @stellar/freighter-api (v6.0.1) for an event/subscription API. The closest thing is WatchWalletChanges, but its implementation (node_modules/@stellar/freighter-api/src/watchWalletChanges.ts) is itself a poller under the hood — fetchInfo re-runs on a setTimeout loop with a default 3s timeout. There is no true push notification for network changes from the extension to the page. So the staleness window can't be closed by swapping polling primitives — it has to be closed at the point that actually matters: the moment a transaction is about to be signed.

Fix

• wallet.ts: WalletService.signTransaction now calls getNetworkDetails() fresh, immediately before every sign dispatch, and throws Network mismatch: Please switch Freighter to {network} if the live passphrase doesn't match the expected one — independent of useNetworkMismatch's cached/polled state. This is the single choke point every write path (mint, burn, admin, metadata, fee bump) already funnels through, via simulateAndSubmit / submitFeeBumpTransaction in stellar-impl.ts. No transaction can be signed while a genuine mismatch exists, no matter how stale the banner is.
• useNetworkMismatch.ts: reduced POLL_INTERVAL_MS from 5s to 2s as a stopgap that shrinks the banner's visible staleness window, with a comment documenting the tradeoff (2.5x more getNetworkDetails() calls) and making clear this is not what prevents signing — that's the check above, which no longer depends on poll cadence at all.

Tests

• wallet.test.ts (new): exercises WalletService.signTransaction directly against a mocked @stellar/freighter-api.
  • Signs normally when Freighter is already on the expected network.
  • Regression test for Network-mismatch polling leaves a signing window between checks #927: simulates a network switch that happened between poll ticks (mocks getNetworkDetails to return a mismatched passphrase, independent of any polling hook) and asserts signTransaction rejects before Freighter's own signTransaction is ever called — proving the block doesn't rely on waiting for the poll's natural cadence.
  • Falls through to Freighter's own signing (and its error surface) when getNetworkDetails() itself errors, so an unrelated Freighter hiccup doesn't block otherwise-valid signing.

Test plan

• npx vitest run — all 47 test files / 464 tests pass.
• npx tsc --noEmit — clean.
• npx eslint on changed files — clean.