openclaw - 💡(How to fix) Fix feat(sessions): add opt-in periodic requester notices for running subagents

Problem

Long-running subagent tasks can spend several minutes in model reasoning or tool execution. Today, parent/main sessions can receive completion events and can inspect task/subagent status surfaces, but requesters still lack an opt-in deterministic "still running" notice while work is legitimately ongoing.

This is a push-side gap, not a pull-side one: #8995's surfaces (task ledger, subagents list, session_status) let a caller ask about state, but nothing tells the parent session that a still-running subagent is still running. In chat-like surfaces, 5-30 minutes of silence looks the same whether a task is slow, stuck, silently failed, or healthy.

Current State

#8995 was closed as implemented because the background task ledger, subagent lifecycle finalization, subagents list, and session_status provide broad observability for spawned work. Those surfaces are useful and should remain the source of truth.

The remaining gap is narrow and push-shaped: there is no opt-in policy for periodically emitting a "still running" notice to the parent session, derived from existing runtime state, without spending an LLM turn.

Proposal

Add an opt-in deterministic notification policy for long-running runtime: "subagent" work.

Illustrative shape; field names are intentionally open to maintainer bikeshedding:

sessions_spawn({
  runtime: "subagent",
  task: "...",
  runTimeoutSeconds: 1800,
  livenessNotify: {
    enabled: true,
    intervalSeconds: 300,
    minRuntimeSeconds: 300,
    target: "requester"
  }
})

Expected behavior:

• No notification before minRuntimeSeconds.
• While the task remains in a running state, emit a compact deterministic notice every intervalSeconds.
• Stop automatically on succeeded, failed, timed_out, cancelled, or lost.
• Do not call an LLM/agent turn to generate notification text.
• Do not claim semantic progress beyond the runtime/task state.
• Dedupe/throttle notifications to avoid chat spam.
• Default behavior remains unchanged unless explicitly enabled.

Why This Is Useful

In a chat UX, silence for 5-30 minutes often looks identical to a stalled or lost worker. A deterministic running-state notice makes long-running work feel reliable without requiring the user to manually poll status.

Non-goals

• Do not replace the task ledger or existing subagent status surfaces.
• Do not require workers to self-report heartbeat files.
• Do not validate output artifacts.
• Do not reopen the full #8995 scope of spawn verification, heartbeat, and completion validation.
• Do not generate free-form progress summaries through an agent turn.
• Do not treat this as health verification beyond existing runtime/task state.

Acceptance Criteria

• A runtime: "subagent" spawn can opt into periodic requester notices.
• Notifications are produced from runtime/task state, not from an LLM call.
• Notification payload includes at least task label or run id, elapsed time, current status, and last activity timestamp when available.
• Notices are delivered via the same channel as existing subagent lifecycle events to the parent/requester session.
• Terminal states clean up the notifier.
• Disabled/default behavior remains unchanged.
• At most one notice is emitted per run id per intervalSeconds.
• No notice is emitted after a terminal lifecycle event for that run id.
• Tests cover normal running notification, terminal cleanup, disabled/default behavior, and throttle/dedupe behavior.