Unbound req in agents/initialize.ts breaks tsc --noEmit on dev #15372

Summary

packages/api/src/agents/initialize.ts:984 references a bare req, which has no binding in that scope. npx tsc --noEmit -p packages/api/tsconfig.json on current dev (30124f21b) fails with:

src/agents/initialize.ts(984,7): error TS2304: Cannot find name 'req'.

Cause

Two recent changes collided:

• 🗿 feat: Add Attached Stateful Code Environments #15352 (Add Attached Stateful Code Environments) added the environments: argument to the resolveCodeExecutionContext call, reading it from req.config.
• 🎻 refactor: Orchestrate Agent Runs Through a Request-Free Host #15366 (Orchestrate Agent Runs Through a Request-Free Host) made the host request-free. After it, req exists only as a field on params (params.req, typed at line 522 and used at line 733). There is no bare req in scope.

const codeExecutionContext = resolveCodeExecutionContext({
  statefulSessions: effectiveStatefulSessions,
  environment: statefulCodeEnvironment,
  environmentId: agent.code_environment_id,
  environments:
    req.config?.endpoints?.[EModelEndpoint.agents]?.statefulCodeSessions?.environments,  // <-- unbound
  userId: requestFileOwnerId,
  agentId: agent.id,
  conversationId,
});

Suggested fix

The adjacent allowlist read a few lines above already uses appConfig for the same config subtree:

params.allowedStatefulCodeEnvironments ??
  appConfig?.endpoints?.[EModelEndpoint.agents]?.statefulCodeSessions?.allowedEnvironments,

so appConfig is in scope and is the same object:

environments:
  appConfig?.endpoints?.[EModelEndpoint.agents]?.statefulCodeSessions?.environments,

That resolves the type error. Worth confirming it is the intended source, since req.config and appConfig could diverge for request-scoped config — if they can, the value may need threading through params instead.

Impact

Beyond the type error, this is a runtime ReferenceError on any path that reaches it with stateful code sessions configured, since the property access is not optional-chained at req itself.

Found while merging dev into a downstream fork; the file is byte-identical to upstream there, so this is not fork-specific.