Support glz::registry and http_router under -fno-exceptions, without hiding errors (#2265)

[stephenberry]

Closes #2265.

The RPC glz::registry (REPE, JSON-RPC, and REST) and glz::http_router could not compile under -fno-exceptions, and route-registration conflicts were silently swallowed to stderr. This PR makes both usable without exceptions and routes every error through an explicit, programmatic channel rather than hiding it. Nothing is swallowed to stderr, turned into UB, or abort()ed.

Design principle: surface errors, never hide them

Glaze's own (de)serialization already reports via error codes (glz::error_ctx/glz::expected), not exceptions. The only throws in this path came from (a) http_router route conflicts and (b) the registry's try/catch around user handler code. Each is given a non-throwing channel; exceptions remain a convenience layer on top, never the only way to learn about a failure.

http_router

• add_route/add now return glz::expected<void, std::string> instead of throwing on a structural conflict (mismatched :param/*wildcard names at a position, or a wildcard that isn't the final segment). Re-registering an identical route still overwrites, as before.
• route()/stream()/websocket() throw on a conflict when exceptions are enabled (restoring the documented @throws contract that the previous stderr-swallow silently violated) and record a queryable error under -fno-exceptions.
• New non-throwing try_route() plus has_route_error() / route_error() / clear_route_error().

glz::registry

• The three handler-invocation try/catch sites are guarded by #if __cpp_exceptions. They only ever guarded user-thrown exceptions, so eliding them under -fno-exceptions is sound.
• New non-throwing try_on() (object and glz::merge overloads) returning glz::expected<void, std::string>.

Failing a request without throwing

A handler may now fail a request by returning glz::expected<T, E>; translation is centralized in each protocol's write_response (no per-wrapper changes). This directly resolves the second half of #2265 ("std::expected to jsonrpc error translation"):

std::function<glz::expected<int, glz::rpc::error>(div_args)> divide = [](div_args p)
   -> glz::expected<int, glz::rpc::error> {
   if (p.b == 0)
      return glz::unexpected(glz::rpc::error{glz::rpc::error_e::invalid_params,
                                             std::optional<std::string>{"b must be non-zero"}});
   return p.a / p.b;
};
// -> {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params","data":"b must be non-zero"},"id":...}

• JSON-RPC error types: glz::rpc::error (full fidelity), rpc::error_e, error_ctx, or any string-like (→ internal error -32603).
• REPE error types: glz::error_code, error_ctx, or any string-like (→ error_code::parse_error, the same code produced when a thrown handler is caught, so throwing and returning an error are equivalent).

Ergonomic handler errors: glz::rpc::result and factory helpers

The full-fidelity error return above is correct but verbose: the return type is written twice and the error is constructed by hand. Thin additions in glz::rpc collapse it, with no change to behavior or wire output:

• result<T> — alias for glz::expected<T, glz::rpc::error>, so the type is not spelled twice (the stored handler signature and the lambda's trailing return type).
• fail(code, data) plus the named helpers invalid_params / invalid_request / method_not_found / internal_error / parse_error — each returns glz::unexpected<error> for that code. The optional argument is carried in the JSON-RPC data member, while message stays the standard text for the code.

std::function<glz::rpc::result<int>(div_args)> divide = [](div_args p) -> glz::rpc::result<int> {
   if (p.b == 0) return glz::rpc::invalid_params("b must be non-zero");
   return p.a / p.b;
};
// -> {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params","data":"b must be non-zero"},"id":...}

This emits byte-for-byte the same response as the longhand above. These are pure additions: the error type and the set_handler_error/write_response translation are untouched, and constructing glz::rpc::error{...} directly remains the path for setting a custom message or an implementation-defined server-error code. The data parameter is std::optional<std::string> — the owned destination type, since a std::string_view would allocate anyway and could not distinguish absent from empty. The docs and the json-rpc example are updated to this form, dropping the now-unnecessary explicit std::optional<std::string>{...} wrapper (a string literal converts implicitly).

Testing

• New registry_no_exceptions_test is compiled twice (exceptions and -fno-exceptions, via glaze_BUILD_REGISTRY_NOEXCEPT_TESTS) and asserts identical behavior: router conflict surfacing, REPE/JSON-RPC expected failure translation, and REST try_on.
• repe_test, jsonrpc_registry_test, and registry_view_test now also build _noexceptions variants; their exceptions-only throwing tests are guarded.
• Full suite builds clean (Debug -Werror, clang) and the registry/router/rpc ctests pass in both configurations.

Compatibility

• No change to the default (exceptions-enabled) behavior for valid registrations or successful handlers.
• Behavior change: a route conflict that was previously logged to stderr and dropped now throws (exceptions) or is reported via route_error()/try_* (no-exceptions). No existing test registered a conflicting route.

This is a from-scratch take on the problem explored in #2564 (compile-only guards) and #2328 (non-throwing registration API); it combines the compile fix with explicit error reporting and adds the handler-failure path neither covered.