Stale task-notifications arrive after output already consumed

Description

When using run_in_background: true in the Bash tool, task-notifications arrive even after the output has already been read. This creates unnecessary token overhead as the LLM must process each stale notification to determine it's already been handled.

Reproduction

1. Run a background task: Bash(command="...", run_in_background=true)
2. Task completes, output file is written
3. Read the output file via Read tool (e.g., after a different signal or manual check)
4. A <task-notification> arrives later for the same task
5. The LLM processes the notification, recognizes the task ID, and discards it

Impact

Each stale notification costs ~30 tokens to receive and dismiss. In a multi-LLM deliberation workflow (5+ background tasks per session), this adds up to ~150+ tokens of pure noise per session.

The LLM cannot prevent, suppress, or dequeue these notifications. The only mitigation is recognizing the task ID and skipping without re-reading the output.

Suggested improvement

A "mark task as consumed" mechanism so the notification system knows not to deliver for tasks whose output has already been read. Alternatively, suppress the notification if the output file has already been accessed.