A pane exit never resolves a loop the daemon knows is live or just restarted

[scgopi]

Why

After Restart All Sessions (0.1.58-beta5), restarted loops showed FAILED. There is exactly one writer of FAILED for an ordinary loop: the app's pane-exit report (nodeCheckRejected), and the daemon only guarded it for remote projects. A pane that watched a restart's kill, a retained pane of a loop switched away from, or Ghostty's own ⌘W close binding in a running pane could all resolve a loop that was still working. Nothing logged why.

What

Daemon

• sessionPermitsResolution replaces the remote-only check. Refuses a pane exit report within 60 s of a restart (the restart's own kill), or when the local session is still alive and not a husk (ZmxSessionLauncher.isSessionAlive, the ensure's own husk-aware check). Remote keeps its presence check.
• Every refusal and every resolution is written to the node's memory log with its cause: resolved: failed — its pane closed with the process still running, … — its workers rolled up to stalled, … — its goal predicate passed.

App

• The loop bar's top-right button is now Restart session; Stop Loop stays in the Loop menu.
• primarySurfaceExited logs a pane exit-finished / pane exit-alive dial line and is dropped while a remount is pending. The case moved to AppFeature+LoopSessions.swift with its siblings.

Verification

• 1499 tests / 155 suites pass in the worktree; swiftlint 0 errors; swift format --strict clean.
• New tests: a check right after a restart is ignored and memoed; a pane closing on a live session is refused until the session is gone, and the failure memo names the cause.

🤖 Generated with Claude Code

https://claude.ai/code/session_0199VUTtyfuWHbu2hHXpHYw2