Worker LLM runtime envs — hot stream timeouts + startup LLM tuning

Problem

QwenPaw workers need tunable LLM streaming timeouts (first-content / idle) and
startup LLM settings, but AgentTeams has no first-class way to set them. Today
the worker entrypoint hard-codes QWENPAW_LLM_STREAM_* to 300s, and changing
them requires a container rebuild/restart — painful when a local SGLang gateway
starves a stream under concurrent load (8/26 QwenPaw001 false-kill precedent).

Proposed

Two paths, matching the QwenPaw env registry's mutability model:

1. Hot stream timeouts — WorkerSpec.llmStreamFirstContentTimeout /
   llmStreamIdleTimeout (+ team-wide TeamSpec defaults) applied to the
   running worker process without a container restart via the worker
   console's /api/envs (PATCH to set, POST .../reset to restore the
   inherited value). Applied state is tracked by the
   agentteams.io/llm-stream-timeouts-applied annotation (first:idle, "-"
   per side), which supports partial clearing: clearing one side while the
   other stays configured resets the cleared key so a stale override is never
   left in the process.
2. Startup LLM tuning — startup-only LLM settings injected at worker start
   (env / runtime block), taking effect on the next (re)start.

Resolution: an explicit worker value always wins over the team default; absent
both means "inherit the QwenPaw entrypoint default" (nothing applied, nothing
to clear).

Intended scope

• Runtime: qwenpaw only — the /api/envs hot registry is qwenpaw
  specific. Other runtimes are a no-op (the hot-apply path returns early).
• Deployment: embedded (in-container worker console reachable on
  127.0.0.1:<console-port>) and k8s. The console dial is a
  trusted-network call (same trust model as the channel/skills/approval
  proxies), no auth.
• Failure semantics: a failed dial logs and leaves the annotation
  unchanged, so the change (and any reset) retries on the next reconcile; the
  worker never loses ownership of an override it still holds.

Companion PR: #1363.

Worker LLM runtime envs — hot stream timeouts + startup LLM tuning

Problem

QwenPaw workers need tunable LLM streaming timeouts (first-content / idle) and
startup LLM settings, but AgentTeams has no first-class way to set them. Today
the worker entrypoint hard-codes QWENPAW_LLM_STREAM_* to 300s, and changing
them requires a container rebuild/restart — painful when a local SGLang gateway
starves a stream under concurrent load (8/26 QwenPaw001 false-kill precedent).

Proposed

Two paths, matching the QwenPaw env registry's mutability model:

1. Hot stream timeouts — WorkerSpec.llmStreamFirstContentTimeout /
   llmStreamIdleTimeout (+ team-wide TeamSpec defaults) applied to the
   running worker process without a container restart via the worker
   console's /api/envs (PATCH to set, POST .../reset to restore the
   inherited value). Applied state is tracked by the
   agentteams.io/llm-stream-timeouts-applied annotation (first:idle, "-"
   per side), which supports partial clearing: clearing one side while the
   other stays configured resets the cleared key so a stale override is never
   left in the process.
2. Startup LLM tuning — startup-only LLM settings injected at worker start
   (env / runtime block), taking effect on the next (re)start.

Resolution: an explicit worker value always wins over the team default; absent
both means "inherit the QwenPaw entrypoint default" (nothing applied, nothing
to clear).

Intended scope

• Runtime: qwenpaw only — the /api/envs hot registry is qwenpaw
  specific. Other runtimes are a no-op (the hot-apply path returns early).
• Deployment: embedded (in-container worker console reachable on
  127.0.0.1:<console-port>) and k8s. The console dial is a
  trusted-network call (same trust model as the channel/skills/approval
  proxies), no auth.
• Failure semantics: a failed dial logs and leaves the annotation
  unchanged, so the change (and any reset) retries on the next reconcile; the
  worker never loses ownership of an override it still holds.

Companion PR: #1363.