enhancement: connect to the daemon lazily instead of failing at startup

## Summary

`arin mcp` aborts at startup when it cannot reach the daemon socket, so an MCP client that launches it before the daemon is up has no Arin tools for the whole session. Starting the daemon afterwards does not recover it, because the client spawns the subprocess once. Connecting lazily on the first tool call would turn a dead session into a single recoverable error.

## Current state

[`serve()`](https://github.com/anistark/arin/blob/aae20a2/crates/arin-mcp/src/lib.rs#L777-L796) connects to the socket and opens a session before it starts serving, and returns an error if either step fails.

The comment above the connect says this is deliberate: "Fail here rather than at the first tool call: a client that cannot reach the daemon should find out while it is still starting up." That holds for a client that surfaces the failure and retries. Claude Code, and MCP clients generally, mark the server failed and carry on, so the session ends up with no Arin tools and no server instructions. The model then has nothing to call and no way to know it was supposed to have anything, which reads to the user as the agent ignoring a request to annotate rather than as a daemon that was not running.

The ordering is easy to hit and easy to hit repeatedly:

- The daemon is a separate process the user starts, and `arin mcp` is spawned by the editor at launch.
- A daemon restarted after an update, or after a crash, leaves every already-running client permanently disconnected.
- Recovery today is restarting the MCP client, which is not obvious from the symptom.

The connection is already indirected in the right place: [`Arin`](https://github.com/anistark/arin/blob/aae20a2/crates/arin-mcp/src/lib.rs#L365-L373) holds it behind `Arc>` and takes the lock for one round trip at a time.

## Proposed change

- Start the MCP server with no connection, and connect on the first tool call that needs one.
- Keep the connection once it is established, and reconnect on the next call if the socket has gone away.
- Return the existing "could not reach the arin daemon on ``; is `arin daemon` running?" wording as a tool error rather than a startup failure, so a model can relay it and try again once the user has started the daemon.

The part worth designing rather than assuming is the session. Every connect calls `start_session`, and the daemon clears a session's marks when it drops, so a reconnect opens an empty session rather than adopting the previous one's marks. That is the right outcome, since those marks went with the daemon, but it is worth deciding whether the reconnect should report them through the existing `gone` field so an agent relying on a mark being visible finds out.

## Acceptance criteria

- `arin mcp` starts and completes an MCP handshake with no daemon running, advertising its tools and its instructions.
- A tool call with no daemon returns an error naming the socket path and how to start the daemon, and leaves the server running.
- Starting the daemon after that and calling again in the same session draws the mark, with no client restart.
- A daemon restart mid-session is recoverable the same way, on the next call.

## References

- [docs/mcp.md](https://github.com/anistark/arin/blob/aae20a2/docs/mcp.md#L21) states "The daemon has to already be running", which relaxes to a first-call requirement.