Expose background task count in statusLine JSON input

Feature Request

The statusLine command receives a JSON payload via stdin with model info, context window, cost, etc. However, several pieces of session state that Claude Code already tracks and displays — background tasks, PR context, and update notifications — are not included in the JSON. Instead, they're rendered as built-in unstyled overlays that share the statusline row.

For users with custom themed statuslines (powerline segments, ANSI styling, etc.), this creates a visual mismatch: half the status area is carefully styled, and the other half is plain text that can't be controlled or suppressed.

Current behavior

Background task count, PR context, and update notifications are rendered by Claude Code outside the custom statusline script's control:

 Model   ctx:65%   repo:branch  Update available! Run: brew upgrade claude-...
PR #1228
3 background tasks

The custom script has no access to this data and no way to suppress the built-in rendering.

Requested additions

1. Expose additional session state in the statusline JSON

{
  "background_tasks": {
    "count": 3,
    "tasks": [
      { "id": "abc123", "status": "running", "description": "Running tests" }
    ]
  },
  "pull_request": {
    "number": 1228,
    "url": "https://github.com/org/repo/pull/1228"
  },
  "update_available": {
    "version": "2.1.73",
    "command": "brew upgrade claude-code"
  }
}

At minimum, just counts/flags are useful ("background_task_count": 3, "has_update": true, "pr_number": 1228).

2. Option to suppress built-in notification rendering

When a custom statusline is active, provide a way to suppress the built-in overlays so the script can handle rendering everything itself. For example, a setting like:

{
  "statusLine": {
    "command": "bash ~/.claude/statusline-command.sh",
    "suppressNotifications": true
  }
}

This is the key piece — exposing the data in JSON is only useful if the custom script has room to render it without competing with the built-in overlays for the same row space.

Why

The statusLine feature is great for customization, but the built-in overlays limit how far that customization can go. The current split — where some status info flows through the custom script and some is rendered around it — means you can't build a fully cohesive status area.

This isn't a request to remove the built-in rendering for everyone. For users without a custom statusline, the current behavior is fine. The ask is: when a user has opted into a custom statusline, give them the data and the space to own the full status area.

Scope

This could easily grow into a large surface area. A practical phased approach:

1. suppressNotifications + background_task_count — highest impact, smallest change
2. pull_request and update_available fields — nice to have, lower priority
3. Full task details (names, statuses) — only if there's broader demand

Workaround

None — the session state is tracked internally but not passed to the statusLine command, and the built-in overlays cannot be suppressed.

Additional context

Related but distinct from #29011 (programmatic task listing via tools) and #27929 (disabling built-in statusline content). This request is specifically about giving custom statusLine scripts full control over the status area.