Event feed, Soroban, allowance and allocation fixes

[Diyaq]

Closes #911, closes #912, closes #917, closes #918.

#911 — ContractEventFeed: topic filtering, reconnect recovery, cursor paging

The issue asks for tests of behaviour the component didn't fully have yet, so this adds two small features and then tests them:

• filterTopics prop. Shows only events whose topics include at least one of the given names (exact match). The event-type toggle counts are worked out from the topic-filtered set. If nothing matches, the existing "No events match the selected filters" message is shown.
• Reconnecting badge. A live poll can fail (an RPC error or a rejected promise) after at least one load has succeeded. In that case the feed now keeps the last good events on screen and shows a Reconnecting… status badge, instead of swapping everything for the hard error view. The next successful poll removes the badge. A failure on the first load, or with polling off, still shows the normal error and Retry button. The polling state is read through a ref so that load doesn't get new dependencies, which would have caused extra fetches.
• Tests (ContractEventFeed.test.tsx):
  • Topic fixtures cover single-topic and multi-topic matching, type counts, the no-match case and an empty filter.
  • Disconnect tests cover an error response, a rejected promise, several failures in a row and recovery, plus the cases that must not show the badge.
  • Cursor tests check that the persisted fromLedger cursor moves forward across pages on consecutive ledgers (100–101 → 102, 102–103 → 104), jumps to the highest ledger when events arrive out of order, and stays put when a page comes back empty.

#912 — SorobanPanel: missing contract banner, args reset on method switch, timers

• Error banner. The error banner now has role="alert" and data-testid="soroban-error". New tests cover a contract that isn't on-chain:
  • an error result that mentions 404 / not found
  • a rejected RPC call
  • simulate mode
  • the banner clearing when the contract ID changes
• Args reset. Changing the method from one loaded ABI method to another now clears the arguments field, so the old method's arguments aren't sent against a different signature. Typing a method name by hand with no ABI loaded, or re-selecting the same method, leaves the arguments alone. Tests cover all of these, including that the invoke call goes out with args: [].
• Timers. The "Copied" test used to just check that the click happened. It now uses fake timers to step through the 1.6s reset exactly (still "Copied" at 1599ms, back to "Copy as cURL" at 1600ms), so it can't race on a slow CI machine. No test in the file sleeps.

#917 — AllowanceManager: self-approval, expiry estimate, revoke confirmation

• Self-approval. There was no spender input, so this adds a New allowance form (token, spender address, amount), opened from the header. validateSpender rejects an empty spender and the active wallet address; the comparison ignores case and surrounding whitespace. The error shows inline under the field (role="alert", linked to the input with aria-invalid / aria-describedby) and disables Approve. handleApproveNew runs the same check again before calling the client.
• Expiry estimate. For allowances that expire at a ledger, the expanded card now shows Expires at ledger N · ~5 days from now (<estimated date and time>). The estimate assumes 5-second ledger closes (estimateLedgerExpiry, LEDGER_CLOSE_SECONDS). If currentLedger isn't known, only the ledger number is shown.
• Revoke confirmation. A confirmation modal already existed. It now has proper dialog semantics (role="dialog", aria-modal, labelled by its title) and a confirm-revoke test id.
• Tests (AllowanceManager.test.tsx):
  • the self-approval block, including a forced submit that never reaches the client
  • approving a different spender
  • the error clearing once the spender is fixed
  • expiry text with a fixed system time, with and without currentLedger
  • the revoke modal: opening it doesn't revoke; Cancel and a backdrop click don't revoke; confirming revokes exactly once
  • unit tests for both helpers

#918 — AllocationInput: invalid-total highlighting, 0.1% arrow steps, Distribute Evenly

• Invalid total. When the total isn't exactly 100%, every row gets a red border, aria-invalid, aria-describedby pointing to the total message, and a ! marker. A new under-allocation message sits alongside the existing over-allocation alert. A form where nothing has been entered yet (total 0) isn't flagged.
• Arrow keys. ArrowUp and ArrowDown now step by 0.1 in code, rounded to one decimal place and kept between 0 and 100, so values don't drift (0.2 → 0.3, not 0.30000000000000004). The step starts from whatever is currently typed. The input keeps step="0.1".
• Distribute Evenly. The existing "Equalise" button is renamed Distribute Evenly. It still works in whole cents, and leftover cents go to the largest current holdings first. The two existing AllocationInput tests and the PortfolioRebalancer tests that found the button by its old name are updated.
• Tests (AllocationInput.test.tsx): highlighting under, over and at exactly 100%; the untouched form; arrow stepping (up, down, no drift, from typed text, limits, other keys ignored); Distribute Evenly with an even split, one asset, a 1-cent remainder, a 4-cent remainder spread across assets, clearing what was being typed, and the disabled state.

Testing

Per this task's rules, nothing was built, linted or run. The new tests are written against the current component code but haven't been run.

🤖 Generated with Claude Code

Closes #911
Closes #912
Closes #917
Closes #918

[drips-wave]

@Diyaq 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