Scheduled task run that fails with 529 Overloaded still sends a completion push notification

## Summary

A scheduled task that fails with a transient server-side error (`API Error: 529 Overloaded`) still counts as a "finished" run and triggers a completion push notification. The user is woken/interrupted on their phone for an infrastructure hiccup that contains no information and requires no action.

## Environment

- Claude mobile app (iOS)
- Scheduled task ("Daily briefing"), recurring, weekday morning
- Model: Opus 5
- Observed: 2026-09-03, ~07:21 local

## Steps to reproduce

1. Create a recurring scheduled task with completion push notifications enabled.
2. Have a run fire at a moment when the API returns 529 Overloaded.
3. Observe: the session transcript contains only the 529 error text (twice, once per retry), and a push notification is delivered to the phone.

## What happens

The run terminates with:

```
API Error: 529 Overloaded. This is a server-side issue, usually temporary —
try again in a moment. If it persists, check https://status.claude.com.
```

The notification layer treats this terminated run as a completed run with a
noteworthy result and pushes it to the device.

## Expected behavior

A run that fails before the model produces any output should not be treated as a
notifiable completion. Specifically, one or more of:

1. **Retry with backoff before notifying.** A 529 is by definition transient. The
scheduler should retry the run (a few attempts over some minutes) and only
surface anything if the retries are exhausted.
2. **Classify run outcomes.** Distinguish `SUCCEEDED` / `FAILED_USER_VISIBLE` /
`FAILED_INFRASTRUCTURE`. Only the first two should be eligible for push.
Infrastructure failures belong in the run log, and at most in email.
3. **Separate the notification channel from the failure class.** If a failure
notification is desirable at all, it should be a distinct, quieter signal —
not the same push the user configured to receive their morning briefing.

## Why this matters

The value proposition of a scheduled briefing is that the phone only lights up
when there is something to read. A notification whose entire payload is "our
servers were busy" inverts that: it is pure interruption with zero information,
and it arrives at exactly the hour the user chose *because* they wanted to be
undisturbed until then. A handful of these trains users to dismiss the
notification unread, which degrades the ones that do matter.

There is also no user-side mitigation. The failure happens before the task's
prompt executes, so no instruction in the task ("exit quietly on error", "do not
report infrastructure failures") can suppress it. The only available workaround
is to disable push for the task entirely — which also disables the notifications
the user actually wants.

## Related

The same class of problem shows up in long-running watcher tasks: a task polling
an external API emitted seven consecutive "check is erroring" emails over two
weeks because each transient upstream 403 was reported as a distinct notifiable
event, rather than being deduplicated or escalated only after N consecutive
failures. Consecutive identical failures should collapse into at most one
notification.

No repository files, tests, or entry points are named. Start by locating the scheduled-task run completion and push-notification handling, then trace how a 529 response is classified after retries. Before implementation, choose the failure and retry policy; done means an infrastructure-only failure does not send the normal completion push, with behavior covered by a regression test.

Written by the indexing model from the issue text.