fix: cancel the pending animation frame on teardown

[david-chau]

Full leak audit of the shipped code. No leaks found. One loose end, fixed
here, which is not a leak.

The loose end

useRejectionFlash schedules two callbacks on a refused keystroke — a
requestAnimationFrame to turn the flag on, a setTimeout to turn it off. The
timer was cleared on unmount and before rescheduling. The frame was neither.

Verified rather than assumed — stubbing rAF and firing the pending callback
after unmount shows it running and setting state on a component that is gone.
React 18 makes that a silent no-op, which is why nothing ever complained.

Retention is one frame, so it never accumulates. But leaving one of two
scheduled callbacks uncancelled is the asymmetry that becomes a real leak the
moment someone moves it to a longer queue.

What the audit checked, and found clean

vector	result
Event listeners	one — the combobox pointerdown, added and removed in the same effect. 500 added / 500 removed over 500 cycles
Timers	one, cleared on unmount and before rescheduling
Animation frames	one — the finding above
Observers / intervals	none
Promises / async	none at all in shipped code
Module-level state	one boolean (flagSupport)
Undo history	capped at HISTORY_LIMIT on all four mutation sites; after 22,000 edits holds one snapshot
Reducer under load	20,000 edits → −0.00 MB
Component under load	20,000 edits → +0.01 MB

A correction to my own measurement

An earlier soak suggested +17.7 MB and looked like a real leak. It was my test,
not the library: I compared against an uncontrolled input that never
re-rendered, so React's re-render cost was being charged to this component.

With a fair control — both controlled, same re-render count:

plain controlled React input   +4.53 MB
FinancialInput                 +0.01 MB

The component is flat, and lighter under load than a plain controlled input.

Verification

1301 unit tests, coverage 100% × 4, bundle 3253 B / 3600 B.

🤖 Generated with Claude Code