Drop the service worker warm-up now that listeners register in time

[sabjorn]

Closes #301

What this changes

Deletes warmServiceWorker() from document_start.ts, and the test that asserted it fired.
document_start no longer communicates with the service worker at all - it is now purely
captureUrlCartParam.

Why it is safe to delete

The warm-up pinged the worker with { contentScriptQuery: 'warmup' } so it would be awake by the
time document_end connected. Nothing ever handled that message - there is no listener for it
anywhere in the codebase - so it always rejected and the rejection was swallowed. Booting the
worker was its entire purpose.

It existed to paper over listeners registering after an await: in MV3, a message or connection
that wakes a sleeping worker is only routed to listeners registered during the worker's initial
synchronous run. That root cause was fixed in #303, which moved every backend's registration into
that synchronous run. With the cause gone, the warm-up has no job.

This is the second half of #301. The first half - the ordering fix itself - landed in #303 while
chasing an unrelated preview-history bug, so only the removal was left.

Verification

Measured against a worker left idle 60-65s with the warm-up removed, so nothing pre-booted it:

Path	API	Result
Theme applied pre-paint	none (registered content script)	applied
Stored preview marks read back	port	253ms / 252ms
Preview click write	port	490ms, persisted across reload
Waveform + BPM	sendMessage	BPM at 3809ms / 4437ms

Both APIs were exercised deliberately. sendMessage mattered most: #301 measured it rejecting
outright against a cold worker before the fix, and it is now answered on a cold wake, twice.

tsc --noEmit clean, 40 files / 776 tests pass, pre-commit hooks pass. The test count drops by
one because the warm-up assertion was replaced with one asserting document_start does not message
the worker at all, guarding against the ping creeping back.

Not verified

findmusic_autologin.ts runs on findmusic.club, has no warm-up of its own, and makes four
sendMessage calls - item 2 of #301. Message dispatch does not depend on the content script's
origin, so the cold sendMessage results above cover the mechanism, but the autologin flow itself
needs a login I could not drive and has not been run end to end. Worth one manual pass before
considering that item closed.