Improve trace durability and error reporting

[madeinplutofabio]

Summary

The current TraceSink::emit_* methods in ncp-runtime return (), so mid-execution trace-write errors are invisible to the embedder. This was documented honestly in docs/MCP_ADAPTER.md §6 Class C as a v0 limitation: the adapter cannot surface a trace_error in structuredContent for mid-call write failures because it has no signal. Real production deployments will need detectable trace I/O failures.

Why this matters

• Adopters running with --trace-dir for audit or compliance need to know if traces are silently failing.
• The MCP adapter has an honest contract today (no synthetic trace_error for mid-execution failures), but that contract was forced by the runtime API limitation.

Acceptance criteria

• Propose a fallible-TraceSink design (emit_* returns Result<(), TraceError>) OR a side-channel error collector (Arc<Mutex<Option<TraceError>>> that the sink writes to and the embedder reads).
• Preserve the invariant that graph execution should not be aborted by trace write failure unless the embedder explicitly opts in to abort-on-trace-error.
• Define how MCP adapters can expose trace_error in structuredContent once the runtime supports detection (matching the future-fix path documented in docs/MCP_ADAPTER.md §6).
• Add migration notes for existing TraceSink implementations (NullTrace, JsonlTraceWriter).
• No implementation required in this issue. Design RFC only. Implementation lands as a follow-up.

Where to read

• runtime/src/trace.rs for the current TraceSink definition
• docs/MCP_ADAPTER.md §6 Class C for the honest v0 contract that documents this limitation
• crates/ncp-mcp-server/src/server.rs for where the MCP adapter would surface trace errors once detectable