Fix scheduled-task completion reporting in the initiating chat

Observed behavior

One-shot scheduled tasks created from this chat emitted duplicate start notifications, but did not deliver their final report back to the initiating conversation.

Two examples:

• Schedule ci-pr-696-results ran a read-only GitHub Actions inspection. The chat received only a start notification and later a completion notification containing the task plan, not the requested inspection result.
• Schedule ci-docs-only-canary-results likewise emitted a start notification. After the GitHub Actions run had completed successfully, ScheduleQuery still reported the fire as in-flight instead of completed and no final report appeared in chat.

The underlying GitHub actions were queried manually and completed; this is a scheduler reporting/lifecycle issue, not an Actions failure.

Expected behavior

• A one-shot fire emits at most one start notice.
• On completion, its actual final result is delivered to the initiating conversation, not its plan/prompt.
• ScheduleQuery transitions the fire from in-flight to completed promptly and records the true stop reason.
• Failed/cancelled fires deliver a clear failure result with available diagnostics.

Reproduction shape

1. Create a one-shot read-only schedule with a prompt that performs a short gh query and reports the result.
2. Wait for its scheduled instant.
3. Observe start/completion messages and inspect the schedule state.

Impact

The current behavior makes schedules unsuitable for unattended monitoring: the operator still has to repeat the read manually and cannot distinguish a delayed result from a lost result.