Summary

• preserve stuck_recovery through reply-run session-id fallback and embedded-run cancel plumbing so recovery no longer degrades into a fake user abort
• require stale tracked progress before active embedded/reply work is abort-drained, even when active-abort recovery is enabled
• add regressions for fresh terminal progress, fresh active reply work, and streamed model progress so long-but-active runs stay alive

Testing

• node scripts/run-vitest.mjs run --config test/vitest/vitest.auto-reply-reply.config.ts src/auto-reply/reply/reply-run-registry.test.ts
• node scripts/run-vitest.mjs run --config test/vitest/vitest.logging.config.ts src/logging/diagnostic.test.ts src/logging/diagnostic-stuck-session-recovery.integration.test.ts
• node scripts/run-vitest.mjs run --config test/vitest/vitest.agents-embedded-agent.config.ts src/agents/embedded-agent-runner/run/attempt.model-diagnostic-events.test.ts

Real behavior proof

• Behavior or issue addressed: Verify that this patch preserves stuck_recovery through the reply-run session-id fallback and does not abort a live embedded run that still has fresh tracked progress.
• Real environment tested: Local OpenClaw checkout on Windows 11 using the real modules from this PR branch via a Node/tsx runtime harness after commit 159943a6c0.
• Exact steps or command run after this patch: Ran pnpm exec tsx - against the real repo modules in this branch with a runtime harness that (1) creates a reply operation and aborts it through abortReplyRunBySessionId(..., { reason: "stuck_recovery" }), then (2) registers an active embedded run, records fresh progress with markDiagnosticRunProgressForTest(...), and calls recoverStuckDiagnosticSession(...) with allowActiveAbort: true.
• Evidence after fix: Terminal output from the local OpenClaw runtime harness after the fix:
  [reply-registry]
  {"aborted":true,"result":{"kind":"aborted","code":"aborted_by_system","reason":"stuck_recovery"},"abortSignalReason":"Reply operation aborted by system reason=stuck_recovery"}
  [stuck-recovery]
  {"snapshotBefore":{"activeWorkKind":"embedded_run","hasActiveEmbeddedRun":true,"lastProgressAgeMs":1,"lastProgressReason":"model chunk observed from runtime harness"},"outcome":{"status":"skipped","action":"observe_only","reason":"active_embedded_run","sessionId":"session-live-progress","sessionKey":"agent:main:main","activeSessionId":"session-live-progress","activeWorkKind":"embedded_run"},"abortCount":0,"cancelReasons":[],"snapshotAfter":{"activeWorkKind":"embedded_run","hasActiveEmbeddedRun":true,"lastProgressAgeMs":84,"lastProgressReason":"model chunk observed from runtime harness"}}
  [diagnostic] stuck session recovery skipped: sessionId=session-live-progress sessionKey=agent:main:main age=180s queueDepth=1 activeSessionId=session-live-progress
  [diagnostic] stuck session recovery outcome: status=skipped action=observe_only sessionId=session-live-progress sessionKey=agent:main:main activeSessionId=session-live-progress activeWorkKind=embedded_run reason=active_embedded_run
• Observed result after fix: The reply-run fallback keeps reason: "stuck_recovery" instead of degrading into a user-abort shape. The live-progress recovery path returns status: "skipped", leaves the embedded run active, and does not call abort or cancel on the active handle.
• What was not tested: I did not rerun a multi-minute end-to-end Feishu + claude-cli channel repro in this environment, and I did not capture UI/video proof from a live chat surface.

Notes

• diagnostics.stuckSessionWarnMs / diagnostics.stuckSessionAbortMs and the default warnMs x 3 / minimum 5 minute behavior are already documented in the current docs/config help, so this PR focuses on the runtime regressions from #88870.

Closes #88870