mcpdo connections/list reports 0 connections, exit 0, when the daemon socket path is over the platform limit #2823

Problem

When the connection daemon cannot start because its socket path is too long for the platform, mcpdo connections/list reports an empty list and exits 0:

Connections (0):

mcpdo connect on the same machine and environment fails loudly. ensureDaemon() calls assertSocketPathWithinLimit() and gives an actionable error ("Connection daemon socket path is too long for this platform (N bytes > 104): …"). connections/list never reaches that check. It is documented as "does not start the daemon", so it calls callDaemon("connections/list") directly, and it treats daemon_unreachable as "no connections" (clients/mcpdo/src/connection/mcp.ts, the connections/list action). A daemon that can never bind therefore looks the same as a machine where nothing is connected yet.

The same fallthrough is in resolveMruEntryName() (servers/show with no name). There it surfaces as "no most-recently-used connection", which is also misleading.

How it was found

The 2.13.0 post-publish smoke installed the published package into a scratch directory whose $TMPDIR-derived daemon directory pushed the socket path past macOS's 104-byte sun_path limit. connect refused with the socket-path error, and connections/list printed Connections (0) with exit 0.

Reproduce

1. Point the daemon directory somewhere deep enough that <dir>/mcpdod.sock exceeds 104 bytes on macOS (108 on Linux), for example a long TMPDIR.
2. mcpdo connect <entry> gives the socket-path-too-long error (correct).
3. mcpdo connections/list prints Connections (0): and exits 0 (wrong: the daemon cannot run at all in this environment).

Expected

connections/list keeps its "does not start the daemon" contract. It should still run the same assertSocketPathWithinLimit() check before treating an unreachable daemon as "no connections", and fail with the same error and a non-zero exit when the path is over the limit. An agent driving mcpdo from a script then sees why nothing will ever connect, instead of an empty list that looks healthy. resolveMruEntryName() should get the same treatment.

Scope

Only the over-limit socket path. A merely absent daemon (path fine, nothing running) correctly reports an empty list and should keep doing so.