proto: give the generated C++ Dispatcher a real error channel (P1, 1.4.0)

DAEMON's daemon/docs/proto-requests-m1.md P1: velox::proto::Dispatcher's
on_* methods returned Result<T> = expected<T, ParseError>, and dispatch()
mapped every handler error to -32603 InternalError. A handler had no way to
return -32010 (download.get not-found), -32011 (download.add invalid-path)
or -32013 (probe-failed) with their data payloads -- three error fixtures a
conformant server must satisfy were unreachable, blocking DAEMON's
"conformance as a server" M1 DoD.

Two error channels now, kept separate on purpose:
  - parse: Result<T> / ParseError -- dispatch() failing to turn the wire into
    typed params. Always -32602, always structural.
  - handler: HandlerResult<T> / HandlerError -- a handler deciding the request
    can't be fulfilled. Carries any ErrorCode + message + free-form data.

    struct HandlerError {
        ErrorCode code{ErrorCode::InternalError};  // bare {} is a valid -32603
        std::string message;
        nlohmann::json data = nullptr;             // straight into the error's data
    };
    template <class T> using HandlerResult = std::expected<T, HandlerError>;

dispatch()'s handler branch is now
  make_error(id, r.error().code, r.error().message, r.error().data)
instead of a hard-coded InternalError. -32001/-32002/-32003 stay the server
layer's to raise around dispatch(), as DAEMON already does.

Verified end to end against the real dispatch() path: a handler returning
TaskNotFound/InvalidPath/ProbeFailed produces -32010/-32011/-32013 with the
data object intact, and a bare HandlerError{} still yields a clean -32603
with no data field. The `= nullptr` on the member (not `{nullptr}`) matters:
brace-init of nlohmann::json from nullptr is the array [null], not JSON null.

FixtureDispatcher regenerated to HandlerResult; conformance_main.cpp only
inspects dispatch()'s JSON and needed no change. TS side is untouched beyond
the version string -- no server Dispatcher is generated there.

P2 also handled: session.hello.version-mismatch's data.expected was a stale
"1.0.0"; now $any, with a note that the error-fixture compare is on `code`
only so a server echoing kProtocolVersion there is fine.

Version: minor, 1.3.0 -> 1.4.0. Wire is byte-identical (no schema, fixture,
or OpenRPC change) but every Dispatcher implementer must swap Result ->
HandlerResult on regen, and the bump is how lanes are told to. Not an ADR:
one lane consumes this binding, it's the one that asked, and the shape is
the one they proposed. Answered in contracts/proto-answers-daemon-m1.md.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012fgjnqFCS5h5L7gZTZo3rV

contracts/README.md

@@ -3,16 +3,18 @@
 **This directory is the interface between every lane.** Owner: agent **PROTO**.
 Nobody else commits here. Everybody else *generates from* here.
 
-> ## Status: **v1.3.0** (frozen at v1.0.0 on 2026-09-09; minor bumps since)
+> ## Status: **v1.4.0** (frozen at v1.0.0 on 2026-09-09; minor bumps since)
 >
 > **v1.0.0** froze 38 methods, 9 events, 26 named types. **v1.1.0** widened `bufferBytes`
-> bounds and added the segment-budget settings (`docs/adr/0012-...`). **v1.2.0** added
-> `download.provideAuth`, F2's credential return path. **v1.3.0** (current) widens when
-> `event.task.state.error` / `TaskSummary.error` are populated to also cover a `paused`
-> the daemon entered unilaterally (`auth_required`, `server_file_changed`, disk full),
-> not just `failed`/`retry_wait` — the wire shape is unchanged (`error` was already
-> `TaskError | null`), only the description of when it's set. Landed for DAEMON's
-> `docs/adr/0013-task-state-machine-ownership.md`. See also `docs/adr/0005-...` for the
+> bounds and added the segment-budget settings. **v1.2.0** added `download.provideAuth`
+> (F2). **v1.3.0** widened when `error` is populated on a state change to cover a
+> daemon-initiated `paused` (for `docs/adr/0013-...`). **v1.4.0** (current) is a
+> **C++-binding-only** change: the generated `Dispatcher` gains a `HandlerError` /
+> `HandlerResult<T>` error channel so a handler can return `-32010` / `-32011` /
+> `-32013` with their `data` payloads instead of collapsing to `-32603`. The wire is
+> byte-identical — no schema or fixture change — but any `Dispatcher` implementer
+> must swap `Result` → `HandlerResult` on regen. Answered in
+> `contracts/proto-answers-daemon-m1.md`. See also `docs/adr/0005-...` for the
 > versioning rule and `docs/adr/0010-...` for the failure taxonomy and segment ranges.
 >
 > Lane requests are answered in writing: `contracts/proto-answers-m1.md` responds to