Add structured diagnostics for daemon IPC requests and broadcasts

[ZekeAranyLucas]

@zaranylucas_microsoft, assigning this to you was rejected by GitHub permissions, so mentioning you here.\n\n## Context

#288 exposed an observability gap: when graphcode mail inbox times out, current logs cannot identify whether the delay occurred while opening the project, decoding or handling the command, persisting state, encoding the graph, broadcasting it, or writing to a slow client.

Today:

• graphcoded.log records only uncorrelated client connected / client disconnected lines without timestamps.
• graphcoded.err.log usually contains no relevant evidence.
• dials.log covers backend session lifecycle, not daemon IPC.
• The CLI reports only a generic error after its 10-second socket receive timeout.

This applies to every daemon command, not only the Mailroom.

Proposed diagnostics

Add structured, timestamped, correlation-friendly diagnostics for daemon IPC:

• request or operation ID
• command kind and canonical project identifier
• encoded request size
• durations for decode, dispatch, persistence, event encoding, and broadcast
• encoded response or broadcast size
• number of intended and successful broadcast recipients
• per-client write duration and failures, including errno
• CLI phase and elapsed duration when a receive timeout occurs
• daemon startup identity/version so logs reveal client and daemon version skew

Privacy and operational constraints

• Never log prompt text, mail bodies, tool output, credentials, repository contents, or raw command payloads.
• Keep logs bounded through rotation or size-based truncation.
• Avoid synchronous logging that can materially affect the IPC path being measured.
• Make request IDs usable across CLI and daemon records.

Acceptance criteria

1. An integration test can inject a slow or non-reading subscriber while another client runs a command.
2. The resulting diagnostics identify the exact phase and client write that exceeded its budget.
3. A large graph test records payload size and broadcast fanout without recording graph content.
4. A CLI timeout message includes its phase, elapsed time, and correlation ID.
5. Logs remain within a documented size bound.

Related: #288

[scgopi]

Closing as a duplicate of #289: same title, same body, same acceptance criteria — this one differs only by the @-mention preamble (with a literal \n that did not render). The work is tracked on #289; the root-cause report that found the duplicate is linked from #288's fixes.