feat(mcp): add diff_ports for observing what a change did

[Mapika]

Second of Tier 3. An agent could already list ports, but not answer the question people actually ask: "what did starting that actually change?" Doing it by hand means calling list_ports twice and diffing JSON in the model's head, which is exactly the kind of thing models get subtly wrong.

diff_ports records a baseline on the first call and reports what changed on the next.

A restart is not a close plus an open

The design decision worth reviewing. Keying by (port, protocol) means a service that came back on the same port keeps its key and changes its PID — reported as replaced:

{"baseline_age_seconds":2,"opened":[],"closed":[],"replaced":[
  {"port":3000,"protocol":"TCP",
   "before":{"pid":6,"process":"node"},
   "after":{"pid":45,"process":"node"}}]}

Reported as a close and an open, that would read as "your service went down and something else took the port" — a materially different and alarming claim. Verified against a real restart: pid 6 → 45 on port 3000.

Keying on (port, protocol) rather than port alone also means a service dropping its IPv6 listener while keeping IPv4 shows up, instead of being masked.

Baselines with a different view are refused

Testing surfaced a footgun: baseline with all=false, then diff with all=true, and every established connection on the machine appears as newly opened. That looks like a real finding and is an artefact. It now refuses with something actionable:

baseline was recorded with all=false, but this call passed all=true. Comparing them
would report unrelated rows as opened or closed. Call diff_ports with all=false to
match, or reset=true to record a new baseline.

Notes

• The diff is a pure function (compute_diff) with no I/O or shared state, so it is unit-tested directly; tool_diff_ports only handles the baseline around it.
• Output is sorted. HashMap order is not stable, and unsorted output would appear to change between two identical calls.
• Offered by --read-only servers: it only reads the machine. The baseline is the server's own memory of a previous look, not a change to anything.
• The instructions string now mentions diff_ports and the kill_port dry run — that string is what the model reads at initialize, and an unmentioned tool is a rarely-used one.

Verification

One long-lived server driven over a FIFO, with real services starting and stopping between calls — the baseline lives in the process, so a canned pipe cannot test it:

==> 1. first call records a baseline
  {"baseline_taken":true,"port_count":1,"note":"Baseline recorded. …"}
==> 2. nothing changed yet
  {"baseline_age_seconds":0,"opened":[],"closed":[],"replaced":[]}
==> 3. start api.js
  "opened":[{"port":8080 …},{"port":8081 …}]
==> 4. restart web.js on the SAME port with a NEW pid
  pid 7 -> 102 → reported under "replaced"
==> 5. reset takes a fresh baseline, so the diff clears
==> 6. diff_ports is offered by a --read-only server

191 tests, fmt/clippy clean, macOS + Windows type-check.

Remaining in Tier 3: process tree in inspect_port.