Disable thread-bound schedules when the destination is archived or deleted, and bound delivery retries#24519

Problem: One retained 5-minute schedule accumulated 1,074 futile scheduler attempts after its destination was archived before the first normal tick. The destination had 0 messages after archival and 0 observed schedule-prompt deliveries, so this was 0 observed model wakeups, not 1,074 inference turns. The final recorded error was ThreadManagementThreadArchivedError; per-attempt error history was not retained, so it cannot establish that every attempt had the identical exception. Rejecting the first archived-destination delivery and retiring the schedule could have prevented up to 1,073 repeated attempts.

Reproduction or observation: Create a thread-bound schedule, archive its destination before its next due occurrence, and advance the scheduler with a test clock. Check whether the task remains enabled and whether attempts continue. Repeat with a deleted destination, a temporary delivery failure, and an archive-versus-dispatch race. These are proposed reproductions; the audit evidence is a retained schedule record and destination timeline, not a new live timer.

Proposed behavior: On archive/delete, disable schedules bound to that destination and preserve a visible retirement reason and delivery history. Recheck at dispatch to handle races. Treat an archived/deleted destination as permanent and do not retry or silently create a replacement thread. For transient delivery errors, use backoff plus an explicit finite retry/delivery-age policy, then surface a terminal failure or paused state. Keep one scheduled occurrence distinct from its delivery retries. Do not auto-enable the task merely because a thread is restored.

Why native: Only the scheduler can reliably coordinate destination state with dispatch and preserve attempt accounting. Agent instructions cannot retire a timer that never successfully delivers, and an external watchdog duplicates the scheduler.