mcpdo: detect a connection daemon from another release instead of failing downstream #2870

Found by Copilot's review of the v2.14.0 milestone merge (PR #2867, thread), and reproduced in the release smoke (#2865). A maintainer decided to fix it in v2.14.0.

What happens

mcpdo never checks that the connection daemon it talks to came from the same release as the client. A daemon stays up while any connection is open (it idles out only after 60 s with no connections), so it survives an upgrade. The upgraded client then talks to the old daemon's code.

On 2.14.0 that breaks --load. #2855 changed the load summary's shape, and the human formatter expects the new fields:

$ (2.13.0) mcpdo connect load --config mcp.json
$ (2.14.0) mcpdo @load tools/call echo message:=x --load --load-requests 20
{"error":{"code":"error","message":"Cannot read properties of undefined (reading 'min')"}}
exit 1

--format json prints the old daemon's summary, without okThroughput, errorLatencyMs or toolErrorMessages. mcpdo daemon status gives no sign that anything is wrong. Any later change to a daemon↔client payload has the same exposure.

Expected

When the running daemon is from a different release, the client says so with an actionable error rather than failing somewhere downstream:

• The daemon reports its package version in its ping reply.
• ensureDaemon() compares that version with the client's own. If they differ, or the daemon reports none (anything older than this change), it fails with a dedicated code that names both versions and says to run mcpdo daemon stop.
• mcpdo daemon stop and daemon status keep working against a daemon of any version, because they do not go through ensureDaemon(). That is what makes recovery possible.

Out of scope

Restarting a mismatched daemon automatically. That would close the user's open connections without asking.