A move made in the terminal reaches the open web pages too #100

I've fixed and pushed the change. The blocking failure was src/write-limit.test.ts, not anything in #31's own feature code (src/watch.ts, src/watch.test.ts were passing every time). That test drains the rate-limit bucket then expects the very next write to be refused, but the bucket refills off the real clock and only needs ~200ms to hand back a token (300/minute limit); sending that check over a real HTTP socket handed the timing to OS scheduling, which is plenty of margin to lose under CI load — a pre-existing fragility that #91's heavier test suite tipped over into a consistent failure.

I rewrote the rate-limit test to call route() directly (the same function the server's fetch handler calls) instead of going over a real socket, so it exercises identical route/rate-limiting code and the same writeBucket singleton, but with no network round trip for a refill to sneak into. Ran the full suite clean five times in a row locally (177 pass, 0 fail). One assertion needed adjusting: bypassing the socket also bypasses Bun's implicit default content-type for a bodied response with none set, so that check now tolerates an absent header the same as text/plain — noted in a comment.

Left everything else about #31's feature (src/watch.ts, src/bus.ts wiring, the terminal-to-web live event) untouched, since it was never the source of the failure.

Closes #31