Expose thread lineage to delegated children in the launch env (T3_THREAD_KIND / T3_PARENT_THREAD_ID / T3_TASK_ID)

[astarktc]

The ask

When Orchestrator V2 launches a provider process for a delegated child (delegate_task, t3_thread_launch-from-agent, scheduled-task runs), expose that fact — and the lineage — in the child's environment. Something like:

T3_THREAD_ID=<this thread's id>
T3_THREAD_KIND=delegated | scheduled | operator        # or T3_DELEGATED_TASK=1
T3_PARENT_THREAD_ID=<orchestrating thread>             # delegated children only
T3_TASK_ID=<the delegated task id>                     # delegated children only

Names are a suggestion; the point is that a launched process can answer "am I a child, and of whom?" without asking the MCP server.

Why

Every Pi launch from T3 currently gets the same three variables (T3_MCP_URL, T3_MCP_BEARER_TOKEN, T3_PI_RUNTIME_MODE) whether it is the operator's main thread or a delegate_task child (verified on b4cc55c24, piT3McpInjection.ts). From inside the process the two are indistinguishable. That blocks two things we actually do:

1. Per-lane configuration. Provider extensions and wrappers key behaviour off "am I a subagent" — e.g. a shorter prompt-cache TTL policy for short-lived children, a leaner system prompt, quieter logging, skipping session-start context injection that only the operator's thread needs. Pi's own subagent tooling sets PI_SUBAGENT_CHILD/PI_SUBAGENT_DEPTH for exactly this reason; T3-delegated children get none of it, so lane-specific config silently applies main-thread policy to every child.
2. Session classification / accounting. Anything that inventories sessions after the fact (usage rollups, transcript analysis, "how much of my spend is orchestration overhead") counts delegated children as independent main sessions, because nothing in the process env or transcript header ties a child to its parent.

The information already exists in the orchestrator at launch time (the task's parentRun.threadId, the task id, the thread kind); it is only missing from the spawn env. The desktop-side change is a few lines in the Pi launch env builder (and the equivalent for other drivers), with no protocol or UI impact.

Scope / non-goals

• Read-only metadata; nothing in T3 needs to consume it.
• No behaviour change for operator threads (T3_THREAD_KIND=operator, or simply the delegated vars absent).
• Happy to send a small PR against the V2 branch if the idea is welcome — keeping it to the env builder + tests.

Context: we run the V2 + Pi-provider branch as a daily driver and hit this while wiring per-lane cache policy (related: #12285, #11168 for other V2 delegate_task contract notes).

[SpyrosPsarras]

One concrete consumer for this: Pi's @gotgenes/pi-permission-system already forwards a subagent's permission prompt to its parent session when the child process has PI_SUBAGENT_PARENT_SESSION=<parent Pi session id>. T3's buildPiRpcLaunch sets no parent, so in a delegated Pi child the prompt stays in the child thread (see #15082). If lineage lands in the launch env, setting that one variable for Pi children under a Pi parent would make these prompts appear in the parent with no other change.

Drafted by Claude Opus 5.5 in the Pi harness inside T3 Code, posted from @SpyrosPsarras's account at his request.