Replace the Server-Sent Events server with an MCP server

[elopez]

Sixth rung of landing #1502 in reviewable pieces, after #1596 (campaign
decomposition) and #1603 (Agent sum type). Stacked on feat/sequence-replay
— review that first; the diff below is only the two commits on top of it.

The preceding rungs built an inter-worker bus and taught a fuzzing worker three
things to do with what arrives on it: enable sampling, fuzz an injected call
ordering, and replay a concrete sequence. None of them had a sender. This adds
the sender.

What changes for users

--server PORT stops serving Server-Sent Events and starts serving MCP at
http://127.0.0.1:PORT/mcp. The flag and the server config key keep their
names and their meaning — a port to serve the campaign on — so there is no
point, in any commit, at which the flag does nothing.

Nine tools. Four report:

tool	answers
status	corpus size, iterations, coverage, tests, optimization values, how long since the last coverage, which functions found it, and whatever is being sampled — as JSON
target	the contract under test and its canonical signatures
show_coverage	one contract's source, marked up line by line
dump_lcov	writes a timestamped LCOV file, returns its path

Five act, over the bus:

tool	does
inject_fuzz_transactions	spends part of every worker's budget on a specific call ordering
clear_fuzz_priorities	undoes the above
sample	starts/stops recording what one function returns and how often it reverts
execute_sequence	replays a concrete sequence and reports on it, leaving the campaign untouched
reload_corpus	picks up whatever was written to the corpus directory since startup

Anything consuming the SSE stream has to move to the status tool. The events
themselves are unchanged in the text, JSON and UI outputs. There is a CHANGELOG
entry, since SSE was never in the README and the changelog is the only place
users will see this.

Retiring SSE is the point, not a side effect

On dev-agents-3 the swap happens by omission — UI.hs drops the import and
runSSEServer is left in the tree with no callers. Here it is deliberate:
Echidna.Server is deleted, wai-extra goes with it, the
"Waiting until all SSE are received..." drain goes, and the MVar the SIGINT
handler filled goes too once nothing reads it.

The dependency is upstream, not a fork

The prototype pinned mcp-server to gustavo-grieco/haskell-mcp-server@3bd3cdc
in both flake.nix and stack.yaml. That rev exists for two Streamable HTTP
conformance fixes — 202 with no body for a notification, 405 for a
server-stream GET — and upstream has since shipped both in 0.2.0.1 on
Hackage, so there is no reason to carry a personal fork of a library in the
closure of a security tool. No fetchFromGitHub.

The cost is one extra pin: 0.2.0.1 needs http-types >= 0.12.6, which both
nixpkgs and lts-23.24 predate. Only 0.12.6 re-exports hOrigin from the
umbrella Network.HTTP.Types that mcp-server imports unqualified, and
http-types has to move for the whole package set rather than for mcp-server
alone, because wai and warp exchange its Status type with it. Everything in
the closure builds against 0.12.6 — but this does mean CI rebuilds that
closure once. The flake.nix override follows the same pattern as the
existing tls pin, with the reasoning in a comment.

Review guide

lib/Echidna/MCP.hs is the bulk. A few decisions in it that are worth a look
rather than a skim:

• mcpApplication under Warp directly, not runMcpServerHttpWithConfig,
  which announces itself with a bare putStrLn. Going through a ServerLog
  event keeps the line timestamped and prefixed like every other one, and
  leaves Warp's settings to us — which is what binds it to loopback.
• Origin validation on with an empty allow-list. The port is
  browser-reachable on localhost, and a page must not be able to drive a fuzzer
  through DNS rebinding. A client that sends no Origin — every CLI agent — is
  unaffected.
• A tool that can't do what it was asked returns an MCP error result, not a
  report whose text begins "Error:", so a model doesn't have to read prose to
  notice. That's the Either in ToolRun.
• reload_corpus decides what's new and adds it in one atomicModifyIORef'.
  Workers append to the corpus while it runs, so a read followed by a write
  would drop whatever arrived in between. Sequences from disk take the weight of
  the best entry already there, never zero — which selectFromCorpus would
  never draw.
• recentFunctions uses takeStrict, not take. Appended on every coverage
  event, read only when a client asks; a lazy tail would retain every sequence
  the campaign ever found coverage with. Same trap the sampling state was
  written around.

Three things from the prototype are deliberately not here:

• Env.sourceCache — DappInfo already carries the source cache, so
  env.dapp.sources is the same thing without a second copy in Env.
• The DumpLcov bus command — it has no sender even upstream (the tool calls
  saveLcovSnapshot directly), so it falls under the same rule the earlier
  rungs used.
• The markLines change — dropping the line number and column separator to
  save an agent's tokens would have regressed every text and HTML coverage
  report Echidna writes, and an agent that can't cite a line number is worse
  off than one reading a few more tokens.

Verification

cabal build clean, hlint lib src clean for every file touched (the one
remaining hint is pre-existing in untouched SourceMapping.hs), all 234 tests
pass.

Beyond that, I drove a real 4-worker campaign over HTTP and exercised all nine
tools, happy path and error paths:

echidna Vault.sol --contract Vault --config config.yaml --server 8123 --format text
# then: initialize, tools/list, and every tool over JSON-RPC

Confirmed: the [Server] banner appears; tools/list reports 9 tools with the
right required arguments; sampling turns on and shows up in status with a
return-value range; execute_sequence classifies completed vs reverted, returns
a trace tree when asked, and leaves coverage and the corpus alone;
inject_fuzz_transactions doesn't stall the campaign; dump_lcov writes a
valid file; reload_corpus adds a hand-written sequence and is idempotent.
Transport: 202 with an empty body for a notification, 405 for a
text/event-stream GET, 403 for any request carrying an Origin. A run
without --server exits normally now the drain is gone, and SIGINT still
stops a campaign with the server up.

Two things came out of driving it:

• reload_corpus returned HTTP 500. It pointed loadTxs at the corpus
  directory itself, whose contents are the coverage/ and reproducers/
  subdirectories — BS.readFile on a directory throws. It now goes through
  loadInitialCorpus, the same path the campaign reads at startup. Fixed here.
• An empty trace field turned out to be a false alarm — my probe sequence
  ended on a call that emits nothing — but the existing assertion in
  Tests/Replay.hs would not have caught a real one: it checks isJust, and
  Just "" satisfies that. Worth tightening; not in this PR.

Known limitations

• execute_sequence sends every call to contractAddr, so a sequence naming a
  function on some other deployed contract goes to the wrong address. The
  sequence syntax has no way to spell an address, and the bus command is already
  fixed as [Tx], so there is nothing to fix it with yet.
• Nothing checks argument types — a call is matched against the ABI by name and
  arity only, same as a fuzzed prototype. Documented in Echidna.MCP.Parse.