[Bug]: Background Auditor keeps foreground runState active and can consume excessive resources

[GTC2333]

Bug Description

A background GoT Auditor is counted as foreground user work by deriveRunActive(). After the Principal and requested subagents have completed, the session can remain runState.active=true for the entire background audit, leaving the UI in a running state and potentially blocking the next user turn.

Steps to Reproduce

1. Start a session with GoT/Auditor enabled.
2. Ask the Principal to launch an expert that runs isolated subagents, then wait for the requested user-facing result.
3. Observe that the Principal and subagents complete and the final answer is visible.
4. Let the background Auditor continue processing or encounter provider retries.
5. Poll session state or observe the Web UI running indicator.

Expected Behavior

Background trace/audit maintenance should not keep the foreground user run active after the requested answer has completed. The audit may continue with its own observable background status, timeout, retry, and token budget.

Actual Behavior

runState.active stays true while the Auditor is running. In a real run, both isolated subagents completed within 12.4 seconds, but the session did not become inactive for about 35 minutes 37 seconds. The run consumed 435,988 tokens including cache reads; the Auditor accounted for 257,461 tokens. Transient provider terminations/retries amplified the delay and cost.

Deployment Method

From source (npm run bp / local mode)

BrainPilot / @brainpilot/app version

0.1.2, commit 59ce2f3

Node.js version

v22.23.2

Operating System

macOS 26.5.2, Apple Silicon arm64

Relevant Logs / Screenshots

Observed timeline:

subagents complete: <= 12.4s
session runState.active=false: ~35m37s
total tokens (including cache reads): 435,988
Auditor tokens: 257,461

Additional Context

packages/runtime/src/session-manager.ts currently contains:

if (a.role !== "trace" && a.status === "running") return true;

Trace is explicitly excluded from foreground activity, but Auditor is not. Consider excluding background Auditor work from foreground runState, while exposing a separate audit status and adding bounded timeout/retry/token limits. This is related to, but not replaced by, #389: a per-session Auditor switch does not fix the default enabled workflow's foreground state semantics.

The run used an Anthropic-compatible third-party gateway with model deepseek-v4-pro; provider retries made the impact easy to observe, but the foreground-state coupling is provider-independent.