docs: Unknown routes are now recorded in HTTP metrics (path="other"), access logs, and request IDs

src/lib/content/getting-started/logging.md

@@ -129,7 +129,7 @@ The event's own fields (`message` and any structured fields) sit at the top leve
 
 ## Request and Response Logs
 
-Every request that matches a route on the main listener is logged inside an `http_request` span that carries `method`, `uri`, `version`, and `request_id`, plus `status_code` and `latency` (microseconds) once the response is ready:
+Except for `OPTIONS`, which the outer CORS layer answers directly, requests on the main listener are logged inside an `http_request` span that carries `method`, `uri`, `version`, and `request_id`, plus `status_code` and `latency` (microseconds) once the response is ready:
 
 | Target | Level | Message | When |
 |--------|-------|---------|------|
@@ -139,7 +139,7 @@ Every request that matches a route on the main listener is logged inside an `htt
 | `smg::response` | ERROR | `request failed with server error` | A 5xx response |
 | `smg::response` | ERROR | `response stream failed after the head was sent` | The response body failed after streaming began |
 
-The logging layer writes one ERROR line per 5xx response; releases before v1.10.0 also logged a duplicate `tower_http` failure line for it (smg-project/smg#2124). A request to an unknown path gets a bare `404` and is not logged.
+The logging layer writes one ERROR line per 5xx response; releases before v1.10.0 also logged a duplicate `tower_http` failure line for it (smg-project/smg#2124). A non-`OPTIONS` request to an unknown path gets a `404` from the gateway's fallback and is logged like any other 4xx: an INFO `started processing request` line and a WARN `request failed with client error` line (smg-project/smg#2679). In v1.11.0 and earlier the fallback sat outside the logging layer, so unknown paths were not logged.
 
 ### Health Probe Logs
 
@@ -462,7 +462,7 @@ smg launch \
 
 ### Request ID Propagation
 
-Every request that matches a route gets an ID. SMG takes it from the first of these request headers that is present: `x-request-id`, `x-correlation-id`, `x-trace-id`, `request-id` (replace the list with `--request-id-headers`). Otherwise it generates one with an OpenAI-style prefix (`chatcmpl-`, `cmpl-`, `gnt-`, `resp-`, `msg_`, or `req-`) followed by 24 random letters and digits. The ID is returned in the `x-request-id` response header and recorded as `request_id` on the request's `http_request` span, so it appears on the lines logged while the request is handled, as long as SMG logs at `info` or more verbose.
+Requests on the main listener get an ID, unknown paths included, except for `OPTIONS` requests answered directly by the outer CORS layer. In v1.11.0 and earlier, a request to an unknown path got a bare `404` with no `x-request-id` (smg-project/smg#2679). SMG takes it from the first of these request headers that is present: `x-request-id`, `x-correlation-id`, `x-trace-id`, `request-id` (replace the list with `--request-id-headers`). Otherwise it generates one with an OpenAI-style prefix (`chatcmpl-`, `cmpl-`, `gnt-`, `resp-`, `msg_`, or `req-`) followed by 24 random letters and digits. The ID is returned in the `x-request-id` response header and recorded as `request_id` on the request's `http_request` span, so it appears on the lines logged while the request is handled, as long as SMG logs at `info` or more verbose.
 
 ```bash
 # Send request with custom ID

src/lib/content/getting-started/monitoring.md

@@ -73,7 +73,7 @@ smg launch \
 | `--enable-trace` | `false` | Enable OpenTelemetry tracing |
 | `--otlp-traces-endpoint` | `localhost:4317` | OTLP gRPC collector endpoint, as `host:port` (`http://` is added when no scheme is given) |
 
-Spans are batched and exported over OTLP gRPC with the service name `smg`. The gateway exports its own request spans: `http_request` for each HTTP request that matches a route (method, URI, request ID, status code, and latency in microseconds) and `grpc_execute` for each dispatch through the gRPC pipeline (request type, request ID, model, and mode).
+Spans are batched and exported over OTLP gRPC with the service name `smg`. The gateway exports its own request spans: `http_request` for HTTP requests on the main listener, excluding `OPTIONS` handled directly by the outer CORS layer (method, URI, request ID, status code, and latency in microseconds) and `grpc_execute` for each dispatch through the gRPC pipeline (request type, request ID, model, and mode). Non-`OPTIONS` requests to unknown paths get an `http_request` span too; in v1.11.0 and earlier, their `404` came from a fallback outside the span layer, so no span was exported for them (smg-project/smg#2679).
 
 ### Trace propagation
 

src/lib/content/reference/metrics.md

@@ -48,7 +48,7 @@ Labels whose values a client can influence are bounded, so unexpected input cann
 
 | Label | Bound |
 |-------|-------|
-| `path` (HTTP metrics) | The matched route template, for example `/v1/responses/{response_id}`. Requests that match no route get a bare `404` from a fallback outside the metrics layer and are not recorded. |
+| `path` (HTTP metrics) | The matched route template, for example `/v1/responses/{response_id}`. Non-`OPTIONS` requests that match no route are collapsed into a single `path="other"` series, whatever their URI (smg-project/smg#2679). In v1.11.0 and earlier their `404` came from a fallback outside the metrics layer, so they were not recorded at all. The outer CORS layer answers `OPTIONS` directly, before the HTTP metrics middleware. |
 | `method` (HTTP metrics) | `GET`, `POST`, `PUT`, `DELETE`, `PATCH`, `HEAD`, `OPTIONS`; any other method is `OTHER`. |
 | `model` | The first 1,024 distinct values keep their own series; every later new value is reported as `other` (smg-project/smg#2093). |
 | `tool_name` (MCP metrics) | Same rule as `model`: 1,024 distinct values, then `other`. |