What Problem This Solves

Fixes an issue where operators running a managed gateway would keep working
with a silently disabled config hot-reload watcher. #92027 and #92852
(both merged) taught the watcher to retry past transient native/polling
errors and record a terminal "disabled" status once retries are
exhausted, but that status was discarded at the managed-reloader boundary
and never reached openclaw health. An operator editing openclaw.json
and expecting a hot reload would see nothing happen, with no way to tell
"the gateway ignored this edit" apart from "the edit produced a no-op
reload plan."

Why This Change Was Made

The watcher already computes the right terminal state; this change is pure
plumbing to surface it, not new reload policy.

Changed surface:

• src/gateway/server-runtime-handles.ts / src/gateway/server-reload-handlers.ts
  — GatewayConfigReloaderHandle gains an optional hotReloadStatus()
  accessor alongside stop(); startManagedGatewayConfigReloader returns
  the watcher's real accessor instead of a handle that only exposes stop.
• src/commands/health.types.ts / src/commands/health.ts — new optional
  HealthSummary.configReload.hotReloadStatus field + a text-output line
  that only prints on "disabled".
• src/gateway/server.impl.ts / src/gateway/server/health-state.ts /
  src/gateway/server-methods/shared-types.ts /
  src/gateway/server-request-context.ts / src/gateway/server-methods/health.ts
  — thread the live accessor through both the full-refresh path and the
  cache-hit merge path (one new GatewayRequestContext getter, wired at the
  single createGatewayRequestContext call site).

Each layer above exists because the health RPC has two independent response
paths (full refresh vs. cache-hit merge), and both already carry other live
runtime facts (eventLoop, modelPricing, contextEngines) the same way —
this change reuses that existing plumbing pattern rather than adding a new
one. No generic "conditions" abstraction was introduced because there is
exactly one signal to surface today; a future second signal would be the
trigger to generalize.

configReload.hotReloadStatus follows the existing modelPricing/
contextEngines sibling pattern: the JSON field is present whenever a real
reloader is running ("active" or "disabled"), and omitted only when
there is no reloader at all (minimalTestGateway, pre-startup inert state).
Text output additionally suppresses the "active" case and only prints a
line on "disabled", matching how formatModelPricingHealthLine and
formatContextEngineHealthLine stay silent on the healthy/ok case.

Non-goals: no new persisted state (the field is derived, not stored), no
doctor repair (this surfaces existing in-memory watcher state, not a
migratable config shape), no generic "conditions" enum (see above), no
change to reload/retry policy.

User Impact

Operators can now run openclaw health (text or --json) and see Config hot reload: disabled (watcher retries exhausted; restart the gateway to restore it) when the gateway's config watcher has permanently given up,
instead of silently continuing to run on stale config with no visible
signal. The status is fresh on every call, including cache-hit responses,
so it's visible immediately rather than after a cache refresh delay.
--json includes configReload.hotReloadStatus whenever a reloader is
running, whether "active" or "disabled"; text output only prints a line
for the "disabled" case, so the common healthy case stays quiet. The
field is omitted entirely only when no reloader exists at all (e.g.
minimal/test gateways).

Evidence

Production-path health capture:

• Booted a real gateway on this branch (isolated OPENCLAW_STATE_DIR/
  OPENCLAW_CONFIG_PATH/port, gateway.auth.mode=none, channels/providers
  skipped so no real credentials were needed) and ran openclaw health --json; the response included "configReload":{"hotReloadStatus":"active"}.
  This validates the "active" plumbing end to end through the real
  production chain (real startGatewayConfigReloader →
  runtimeState.configReloader → GatewayRequestContext →
  healthHandlers.health → JSON output), not just a mocked/unit-test path.
• This capture does not by itself validate the "disabled" path in a
  running production gateway — that terminal transition is covered
  separately by src/gateway/config-reload.test.ts's existing real-watcher
  retry/polling exhaustion test (cited below), not a live capture. Forcing
  real chokidar/inotify exhaustion in a production-path capture would be
  flaky and wasn't attempted.

Existing signal proof (unchanged, cited not duplicated):
src/gateway/config-reload.test.ts:1675 — "degrades to polling then disables after both native and polling retries are exhausted" — already
proves hotReloadStatus() flips "active" → "disabled" after native +
polling retries are exhausted (introduced by #92027/#92852).

New plumbing proof (src/gateway/server-reload-handlers.hot-reload-status.test.ts):
mocks startGatewayConfigReloader to return a controllable live accessor,
then proves startManagedGatewayConfigReloader(...).hotReloadStatus is a
function that reflects a live mutation of the underlying watcher's status
("active" → "disabled") without recreating the managed handle — this is
exactly the regression a copied/snapshotted value would fail.

New health summary proof (src/commands/health.snapshot.test.ts):

• "omits configReload when no config reloader status is supplied"
• "surfaces a disabled config hot-reload watcher in the health snapshot"

New health-state passthrough proof (src/gateway/server/health-state.test.ts):

• "passes the config reloader hot-reload status only when the hook returns one"
  (mirrors the existing getEventLoopHealth passthrough test)

New cache-hit freshness proof (src/gateway/server-methods/server-methods.test.ts,
describe("gateway healthHandlers.health cache freshness")):

• "merges a live disabled config hot-reload status into cached health responses"
  — cached snapshot says "active", live accessor says "disabled"; the
  cache-hit response ({ cached: true }) reflects "disabled" immediately
• "preserves the cached config hot-reload status when no live accessor is available" — no getter on context → last cached value survives unchanged

New live request-context read proof (src/gateway/server-request-context.test.ts):

• "reads config hot-reload status live from runtime state" — proves
  context.getConfigReloaderHotReloadStatus() reflects live mutation of
  runtimeState.configReloader at the single wiring site, mirroring the
  existing live cron / cronStorePath request-context read tests.

New CLI output proof (src/commands/health.test.ts):

• formatConfigReloadHealthLine unit tests: disabled → line text, active →
  null, absent → null
• "surfaces a disabled config hot-reload watcher in JSON output"
• "prints the config hot-reload disabled line in text output"
• "omits the config hot-reload line in text output when the reloader is active"

Validation run (worktree repo/worktrees/config-hot-reload-health-status,
node scripts/run-vitest.mjs, rebased onto upstream/main
dad7768da8500d1c785ef33e19aabee9d01081bd):

• src/gateway/config-reload.test.ts — 304/304 passed
• src/gateway/server-reload-handlers.test.ts +
  src/gateway/server-reload-handlers.hot-reload-status.test.ts +
  src/gateway/server-request-context.test.ts +
  src/gateway/server-methods/server-methods.test.ts +
  src/gateway/server/health-state.test.ts (gateway config project,
  15 files) — 553/553 passed
• src/commands/health.test.ts + src/commands/health.snapshot.test.ts —
  35/35 passed
• pnpm exec oxfmt --check on all touched files — clean
• node scripts/run-oxlint.mjs on all touched files — clean
• node scripts/run-tsgo.mjs -p tsconfig.core.json (prod typecheck) — clean
• node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json (test
  typecheck) — clean
• node --import tsx scripts/check-import-cycles.ts — 0 runtime value cycles

No live/E2E proof was added beyond the production-path capture above: this
is plumbing of an already-tested terminal state through existing accessor
boundaries, not new watcher/chokidar behavior, so no OS-specific or
timing-sensitive CI test was introduced per repo guidance against flaky
watcher tests in CI.

Precheck note

• ocw review precheck config-hot-reload-health-status reached the broad
  gateway-server Vitest lane but failed in pre-existing shared-lane tests
  unrelated to this branch.
• Minimal reproducer with zero files from this branch:
  node scripts/run-vitest.mjs run --config test/vitest/vitest.gateway-server.config.ts src/gateway/server.health.test.ts src/gateway/server-startup-log.test.ts
  reproduces the same server-startup-log.test.ts warning failures.
• The reproducer files and root-cause helper are byte-identical to
  upstream/main; this branch does not touch them.
• Root cause: src/gateway/test-helpers.mocks.ts mutates
  process.env.OPENCLAW_SKIP_CHANNELS = "1" at module top level without
  cleanup, then leaks across the non-isolated gateway-server project
  depending on file order.
• This branch's own focused tests, typecheck, lint, import-cycle checks,
  and production-path health capture all passed.