[FEATURE] Expose context-window usage to subagents so they can self-delegate before quality degrades

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Agents have a usable "smart" zone and a degraded "dumb" zone of their context window.
Empirically, output quality drops well before the hard limit (cf. self-reported
degradation in long sessions). A subagent spawned via the Task/Agent tool currently
has no in-turn signal of how much of its own context it has consumed, so it cannot
make the single most valuable decision available to it: hand its remaining work to a
fresh agent before it enters the degraded zone.

The context-usage signal already exists — the statusline renders it for the main
agent. It is simply not surfaced for subagents: not to the human (statusline shows
the main agent only; cf. #65792 / #58523 / #68555 requesting per-agent display in
FleetView) and not to the subagent itself in-turn. This request targets the second,
unaddressed gap: making a subagent aware of its OWN context so it can self-handoff
before the degraded zone. Since the metric is already computed for the statusline,
exposing it to the owning subagent is incremental, not new infrastructure.

Proposed Solution

Expose the agent's own live context usage to the agent itself, at minimum for
subagents spawned via the Task/Agent tool. Solution is up to you, as you know the harness better than me.
Also main agent should be able to see this metric for any subagent by it's name.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

1. My orchestrator agent is working and organizing other agents.
2. After some time it's context runs past 40% of it's capacity and moving slowly into dumb area.
3. It notices that and starts a handoff protocol, which will spawn another orchestrator
4. It hands off the work without the obsolete knowledge that is taking up space in it's context.
5. New orchestrator takes over the responsibilities of the old one, but with clean context.
6. Old Orchestrator can be shut down

Additional Context

_No response_