🚧 Retry reporting after finalization

[ashb]

Delay retry reporting until task finalization completes

Reporting a retry to the API can replace the task instance UUID before
on_retry_callback has run. The callback and other finalizers still use
the old UUID, so their API calls can fail even though they are part offinishing that attempt.

This changes things so we hold the RetryTask message until the worker
exits. Heartbeats continue while finalization runs, and the existing
overtime limit still applies. Server-directed termination discards the
pending report.

The report keeps the original end date, retry delay and reason. We don't
add the retry delay again after finalization, but if that delay expires
while callbacks are running, the next attempt now waits for them.

Other outcomes are reported at the same point as before. In particular,
success still reaches the server before callbacks run, so this doesn't
delay downstream scheduling on success.

Task Outcome	Before	After
Success	Before finalization	Unchanged
Skipped	After worker exit	Unchanged
Failed	After worker exit	Unchanged
Retry	Before finalization	After worker exit
Deferred / rescheduled / awaiting input	Immediately	Unchanged

The tests check that retry callbacks can still use the original attempt,
including through dag.test(), and that callback errors don't prevent the
retry report. They also cover heartbeats, the finalization timeout, and
external state changes while the report is pending.

Built on top of #73249