mcphttp: pin Flush with a flush that precedes any write

Deleting the Flush method left every test in this package green. All of
them wrote before flushing, which commits the headers through the Write
hook and leaves the flush path unmeasured — the second vacuous test in
this file, after the Unwrap one.

The case that needs Flush is a handler that flushes first, as an SSE
handler opening a stream does. It has to run against a real server:
httptest.ResponseRecorder's Header() hands back the live map, so a
recorder reports the headers as set whenever they were set, and passes
for exactly this bug. Found by an agent that measured it in a sibling
service's copy of this code.

mcphttp: test Unwrap for what it actually carries

The comment claimed Unwrap was what kept streaming alive, and the test named
after that claim passed with the method deleted. Both were wrong, and wrong
for the same reason: cacheWriter has its own Flush, and
http.NewResponseController prefers a method on the writer it is handed over
one reached by unwrapping, so the flush path never unwraps at all.

What Unwrap does carry is everything else the controller offers — the
deadlines and Hijack. A long-lived MCP stream is the response that wants its
write deadline pushed out. The new test measures that against a real server,
because a recorder supports no deadlines either way and would have been
vacuous a second time.

Found by an independent reviewer that mutated the method away instead of
reading the comment.

mcphttp: the MCP endpoint plumbing both services already share

hostAllowed is byte-identical in cov and bench, and neither should own it.
PrivateCache is cov's alone today, which is why bench's /mcp currently sets
no Cache-Control and no Vary at all. StreamableOptions carries the pair both
pass and the reason for it.

HostGuard takes cov's fail-closed stance: an origin with no host to guard
with is a construction error, not a warning. bench serves unguarded in that
case and has a test pinning it; reconciling that is bench's to do.

Deliberately not a shared MCP framework. Once the go-sdk and the per-service
tools are subtracted, this is the whole overlap.