agent(discovers): complete tasks whose discovers row was deleted

[jshearer]

Description:

Deleting a draft cascades to its discovers rows, but their tasks remain in internal.tasks. DiscoverExecutor then fails to load the discovers row on every attempt, and the automations server retries the task after each heartbeat timeout, indefinitely.

When fetch_discover finds no row, the executor now returns DiscoverOutcome::Deleted, which applies as Action::Done and removes the task. The connector is not invoked. Other database errors propagate as before, so the task is kept and retried.

If the draft is deleted while a discover is running, that attempt still fails when applying its results, since the draft and discovers rows are gone. The next attempt, after the heartbeat timeout, finds no discovers row and removes the task. Tasks orphaned before this change are removed the same way on their next retry.

Workflow steps:

No user-facing change.

Documentation links affected:

None.

Notes for reviewers:

• fetch_discover now returns Option<Row>, matching fetch_alert_by_id. The query text is unchanged, so .sqlx/ needs no update.
• The orphan path clears the inbox because Action::Done only removes a task that ends up suspended. A task with unconsumed inbox messages is re-polled instead.
• New tests in integration_tests/user_discovers.rs compare internal.tasks before and after each attempt:
  • Draft deleted before execution: only the orphaned task is removed, and the connector is not invoked. Another queued discover is kept and later succeeds.
  • Draft deleted between the connector response and applying results: the apply fails, and the next attempt removes the task.
  • Lookup fails with a lock timeout on discovers: ObjSafe::poll returns the error, the task is kept, and a later attempt succeeds.
• graphql: add discovery APIs #3545 also edits discovers.rs and user_discovers.rs. The branches change different regions of both files and merge without conflicts.