Symptom

`src/utils/fetch-timeout.ts` emits 6 "fetch timeout reached; aborting operation" warnings/day in our home-prod openclaw-nyla deployment, but the structured fields `operation` and `url` are absent — making the warnings unactionable.

Sample (from Loki, querying `{service_name="openclaw-nyla"} |~ "fetch timeout reached"`):

``` fetch timeout reached; aborting operation fetch timeout reached; aborting operation fetch timeout reached; aborting operation ```

No labels exposed in the Loki stream beyond service_name + level.

Why this happens

`fetch-timeout.ts` already attaches `operation` and `url` to the structured log record (lines 76-90), but only when callers pass them through `buildTimeoutAbortSignal({ operation, url, ... })`. Many callers don't:

```bash $ grep -rn buildTimeoutAbortSignal src/ | wc -l

(expected: many call sites, several without operation/url)

```

Proposed change

1. Audit all callers of `buildTimeoutAbortSignal` and ensure each passes `operation` (required) and `url` (optional but strongly preferred).
2. Make `operation` required in the type signature so future callers can't silently drop context.
3. Optional: include `phase` from the active openclaw lane/phase context if available, so timeout warnings correlate to which subsystem stalled.

Why it matters

"fetch timeout" in a homelab observability stack should be the kind of thing you can drill straight into — "which fetch, where, why now." The current bare-line warnings force a code-spelunk every time.

Source

Discovered during shiori observability deep-dive 2026-05-08.