Cut allocations from event binding and prop application

[amritk]

Summary

Binding an event and applying a prop are what every row of every list does, and both were paying for a general shape on every call while using it almost never. Profiling scripts/bench-reconciler.ts put add-event.ts at ~15.7% self time — well ahead of the reconciler — with the worklet registry and prop parse behind it.

Changes

add-event.ts

• Keep an element's pairs in a short array instead of a Map keyed by a "type:name" string built on every bind and every detach. The strings compared are the interned ones apply-prop.ts already caches, so the walk is usually a pointer compare over one or two entries.
• Store a lone handler directly on its registration, promoting to a Set only when a pair genuinely gains a second handler. Fan-out behaviour is unchanged: handlers stay isolated, dispatch still walks a copy when there is more than one, and the engine still sees exactly one dispatcher per pair.
• Match the registration by identity on detach rather than looking it up again by name, so a stale dispose is harmless and cannot reach a fresh registration that a re-bind put in its place.

apply-prop.ts

• Replace the per-prop closure that bind needed with shared module-level appliers taking the element and name as arguments. A static prop — most props, on most elements — now allocates nothing to be applied; only a getter pays for the one closure its effect needs.
• A show getter is now read once per update instead of twice.

core-size-budget.test.ts

• Raise the ceiling 5560 → 5726 gzipped bytes and record the move in the docstring alongside the three before it, with the measurements behind it. This is the reviewable decision in the PR — the budget sits deliberately snug, and the alternative is keeping only the single-handler fast path for ~92 bytes instead of 166, which gives up about half the win.

Testing

Isolated, against a host that does nothing — the changed code itself:

	before	after
bind + dispose 100,000 listeners	145 ms	62 ms
apply 200,000 static attributes	18.9 ms	2.8 ms

End to end through scripts/bench-reconciler.ts, where roughly half the time is the fake engine's own bookkeeping (medians of three fifteen-sample runs, engine-call counts identical in every case):

Operation	before	after	Δ
create 10,000 rows	260.0 ms	184.6 ms	−29%
clear 1,000 rows	5.63 ms	4.55 ms	−19%
replace all 1,000 rows	28.1 ms	23.8 ms	−16%
partial update (every 10th)	0.36 ms	0.32 ms	−11%
create 1,000 rows	21.6 ms	19.8 ms	−8%
swap / remove / select	—	—	unchanged

Swap, remove and select being unchanged is the check that the story is the right one: they reconcile without building a row, so they bind no listener and apply no prop.

One rejected change worth recording: replacing the list reconciler's per-pass Set with a pass-stamp on each entry (three hash lookups per row down to one) measured as a large regression — creating 10,000 rows went 181 ms → 453 ms, because the stamp turns one compact write into N scattered heap writes. Not included here.

• bun run test passes
• bun run check passes
• bun run check:reactivity passes
• bun run types:check passes
• bun run build passes
• Changeset added (bunx changeset) if this affects a published package

Behaviour is covered by the existing suites — 627 mini-lynx tests, including the 103 that pin event binding, fan-out, dispatch isolation and detach lifecycle. @amritk/mini is untouched.

Related issues