fix(dashboard): search on Enter, not while typing; repoint three stale comments

[dvcdsys]

Two small, unrelated things, batched because both are one-line-class and the release is waiting.

1. /search fired while typing

The page debounced the input into the URL after 250 ms idle, and a URL change is what runs a search. Usual pattern, wrong here: a semantic search embeds the query through the configured provider, so every pause while typing spent a real API call and a full fan-out to answer a half-written question.

retry with exponential backoff typed at a normal pace fires on retry, retry with, retry with expo — three searches nobody asked for and one they did. On a metered provider that is money; on a local sidecar it is a queue of pointless work in front of the query the user meant.

Typing now changes local state only. The URL, and therefore the search, moves on submit. SearchBar already had the onSubmit path — only the debounce had to go. The empty state now says press Enter to search instead of implying results arrive on their own.

Verified through the real component in devmock (boots the app with a mock fetch, no login): typing 31 characters one at a time issues zero search requests; submitting issues exactly one; no navigation.

Worth recording how that was verified, because the first attempt was worthless: driving Enter through the browser-automation key API produced a page "reload" that looked like a regression. It was not — a keydown listener on the input recorded nothing, so those key events never reached the page and the test asserted nothing at all. The real check goes through form.requestSubmit(), the exact path a keypress takes.

2. Three stale comments in workspacesearch.go

All three are from #265 and all three describe code that commit changed:

• projectHits' doc said the two sides "are fused inside the goroutine". They are not — fuseRRF runs in the serial loop after g.Wait(), and the comment above that loop says so in as many words. The struct doc contradicted a comment 650 lines below it.
• the handler doc said "each project runs two queries in parallel: dense and sparse". There is one BM25 query for the whole workspace now — that was the point of perf(chunksfts): rank the whole workspace in one FTS5 query #265.
• BM25Signal's doc explained its normalization but never said it is computed on the raw, unfused list while FusedChunks beside it is post-RRF. That asymmetry decides whether a panel reorder means what it appears to mean.

Same class as 7cc70a2 and two commits in #266: the code moved, the comment above it did not.

Checks

go test ./... green, go vet clean, gofmt clean on the touched files. Dashboard built with npm run build (tsc -b + vite) — the dashboard build is not on PR CI, so it was validated locally.