Fix client router intercepting JS-handled forms (chat/comments navigate on send)

[vivek7405]

Summary

Closes #150.

In the demo blog, sending a live chat message sent the message but then scrolled
the page to the top and the just-sent message vanished. Same class of bug for
the live comments thread.

Root cause: the client router's submit listener was on document in CAPTURE
phase (since e59f381, not a recent change), but a component's @submit is
bound per-element and runs at-target, AFTER document capture. So for a
JS-handled form (chat/comments e.preventDefault() and send over WebSocket /
fetch), the router's onSubmit ran first; its if (e.defaultPrevented) return
guard saw false (the component had not run yet), so it intercepted the form:
with no action it fell back to the current URL and navigated/swapped the page.
The message was sent AND the page swapped, scrolling to top and wiping the
WebSocket-driven chat state.

Fix: register submit in the BUBBLE phase (capture: false) so the component's
@submit runs first and its preventDefault makes the guard skip the form,
honoring the documented "forms that preventDefault in @submit are untouched"
contract. Plain progressive-enhancement forms (no @submit) still get
intercepted and SPA-submitted. Click stays capture. Mirrors hotwired/turbo,
which performs the submission in a bubble listener.

Test plan

• New e2e regression: sending a chat message keeps you on the page and the
  message survives. Verified it FAILS on the reverted (capture) code
  ("the sent chat message must remain visible") and passes with the fix.
• npm test green (1476)
• e2e green (51) against the blog in dist mode (dist rebuilt with the fix)
• Dogfood: blog e2e 51/51 (incl. the chat regression); website / docs /
  ui-website boot 200 in dist mode

Note: the unit env (linkedom) does not model capture/bubble ordering of a
document-level vs element-level submit listener faithfully, so the regression
lives at the e2e layer where real event phases apply.

After merge

Needs a Railway redeploy to reach the live blog (the deployed services auto-deploy
on push to main).

[vivek7405]

Self-review

Loop ran two rounds, last clean.

• Round 1 found: the onSubmit JSDoc still said "capture phase so we run before user @submit handlers" (exactly backwards after the fix); the chat e2e used a fixed sleep that could flake; and click stays capture, carrying the same latent @click-preventDefault hijack. Fixed in c513948: rewrote the JSDoc to describe the bubble ordering, switched the e2e to waitForFunction polling (still times out and fails on the buggy code), and added a NOTE at the click registration deferring that case to its own change, filed as Client router click listener is capture-phase: same @click preventDefault hijack as the submit bug #153.
• Round 2: clean. Verified the removeEventListener flags match (submit … false in both enable/disable), no other comment still calls submit capture, the click NOTE is factually accurate, and the e2e polling has teeth.

Verified: chat e2e passes with the fix and fails on the reverted (capture) code ("the sent chat message must remain visible"); node suite 1476; e2e 51; website / docs / ui-website boot 200 in dist mode.

Follow-up: #153 tracks moving the click listener to bubble for the same reason (out of scope here; doesn't affect the blog, whose nav is plain <a href>).