fix(launcher): dedupe release tweens

[lfkdsk]

The launcher sends the same settle tweens twice on every key release.

onRelease calls setSel(settle) and then unconditionally calls
applyTweens(settle). When the selection actually changed, the createEffect
that watches sel() re-runs in the same frame and issues an identical tween
batch, so the explicit call is redundant. The engine treats the duplicate as a
no-op (spawn() kills the existing track and re-snapshots from from the
current resolved value, and nothing ticks between the two calls), so the extra
work is invisible on screen but real on the wire.

Recording the prior selection and only issuing the explicit tweens when the
selection did not change removes the duplicate while keeping both paths:

• selection changed -> the effect glides the cards home;
• selection unchanged (the effect will not re-run) -> the release path issues
  the tweens itself.

Deleting either path instead would regress: without the explicit call a long
hold that ends on the same card stops animating, and without the effect a touch
tap that only calls setSel stops animating. Both were verified as permanent
divergences, not one-frame blips.

Measured

On the launcher's canonical 180-frame replay (measured at 1b452c1, before the
rebase onto current main):

	before	after
in-frame host calls / bytes	930 / 33,360 B	474 / 20,592 B
exact same-frame duplicate animate	456 / 12,768 B	0 / 0
each release frame	154 calls / 4,344 B	78 calls / 2,216 B
idle frames	0	0

Frame output is unchanged: the canonical replay plus long-hold, touch-tap and
idle tapes all match their pre-change per-frame framebuffer hashes.

Verification

bun tools/test.ts and bun tools/tape.ts replay hero-main --assert were run on
this branch and on a pristine main worktree. Both show the same pre-existing
failures — five unit tests (pocket-package corpus, four ipodtouch4-installation
cases) and a frame-0 divergence of the committed hero-main tape hashes — so
they are not introduced by this change.