wasm: keep one pending scheduler wakeup instead of leaking a timer chain

[0pcom]

sleepTicks armed a fresh setTimeout on every call and never cancelled the
previous one. Its callback calls go_scheduler(), which re-enters the
cooperative scheduler, which calls sleepTicks again whenever it finds nothing
runnable but something sleeping (scheduler_cooperative.go:258, and :285 on
wasmexport return). So each armed timer replaces itself indefinitely, and every
JS→Go callback that reaches the scheduler starts another such chain. Nothing
cancels one, so the pending count grows without bound.

The scheduler only ever needs one pending wakeup — the earliest deadline. This
tracks it and drops any request that is no sooner than what is already armed.
run() also clears a wakeup left over from a previous run, which would
otherwise suppress the first one the new run asks for.

Measured in Chrome with the same wasm binary both times — 50 sleeping goroutines
and a requestAnimationFrame loop — counting setTimeout calls per second:

	t+3s	t+20s	t+40s
before	487/sec	1,498/sec	2,509/sec
after	9/sec	5/sec	5/sec

A larger application reached ~2,800/sec inside a minute. Go-side timing is
unaffected — a goroutine sleeping in a loop still advances exactly 3s over 3s of
wall clock — and frame pacing is unchanged at ~59fps with the animation
rendering correctly.

Only targets/wasm_exec.js changes, so there is no Go code to make fmt; I
verified the file parses and exercised it in a browser rather than running the
full suite.

Fixes #5621