Batch delete confirmation shows stale dirty/unpushed for stopped sessions

[d0ugal]

Summary

confirmBatch displays DIRTY and UNPUSHED columns from protocol.SessionInfo, but these fields are populated by the daemon's background refresh loop which explicitly skips non-running sessions.

Impact

This is especially risky for gr delete --stopped: stopped sessions can have dirty files or unpushed commits, but the batch confirmation table shows DIRTY no / UNPUSHED -. The user is misled about whether it's safe to delete.

Single-session confirmDelete does a live git check; batch delete does not.

Suggested Fix

Recompute dirty/unpushed state for matched sessions before displaying the confirmation table, or reuse confirmDelete-style live checks. Surface git check failures prominently.

Found during review tribunal audit.

[d0ugal]

Still present. The batch confirmation table (internal/cli/batch.go:116-117) shows daemon-cached Dirty/UnpushedCount, which are only populated for running sessions (internal/daemon/daemon.go:3440 skips non-running). Single-session delete does a live git check (delete.go:132-143); batch delete does not. So gr delete --stopped can show DIRTY no for a stopped session with real uncommitted work. Fix: recompute git state for matched sessions before confirming (reuse the single-session live check).