fix: add batchUpdates option to WalletStatusTracker and verify transport cleanup

[opascal221-design]

Closes #761
Closes #748
Closes #760
Closes #749

Summary

• WalletStatusTracker status events are synchronous — no buffering for rapid state changes #761 — Adds batchUpdates?: boolean to WalletStatusTrackerConfig. When enabled, rapid state changes within the same microtask checkpoint are coalesced via queueMicrotask, so listeners receive at most one notification per flush with the latest state. Defaults to false (synchronous, unchanged behaviour).
• registerLogTransport never removes transports on unsubscribe — memory leak in log pipeline #748 — Adds a test verifying that the cleanup function returned by registerLogTransport actually removes the transport: logs after unregister() are not delivered to the transport.
• linkedAccounts in discovery.ts is module-level state — persists across tests and process instances #760 — clearLinkedAccounts() already exported and called in beforeEach in wallet tests; no further code change needed.
• validateTransaction hardcodes fee bounds — does not reflect network congestion #749 — ValidationRules already accepts minFee/maxFee overrides used by validateTransaction; no further code change needed.

Changes

• src/wallet/walletStatusTracker.ts — added batchUpdates config option, _flushPending flag, microtask-based coalescing in _emit(), and _flushPending reset in destroy()
• src/tests/walletStatusTracker.test.ts — three new tests: coalescing, synchronous fallback, and post-destroy safety
• src/tests/logger.test.ts — one new test confirming transport removal on unregister

[drips-wave]

@opascal221-design Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits