'Session in use' warning shows misleading 'last active' timestamp (uses lock file mtime instead of session activity)

[CianH]

Describe the bug

When the 'session in use by another CLI or application' warning fires on --resume, the 'last active' duration string is calculated from the lock file's mtime rather than the session's actual activity timestamp. This produces misleading messages like "This session was last active 3w ago and appears to be in use" even when the session has been actively used minutes ago by the locking process.

Affected version

1.0.40 (reproduced just now)

Steps to reproduce the behavior

1. Pick a session ID that exists in ~/.copilot/session-state/ and a PID that is not currently running (e.g. 99887):

   SESSION=<session-id>
   FAKE_PID=99887
   ps -p $FAKE_PID > /dev/null && echo "PID in use, pick another" || echo OK

2. Note the current mtime of the session's events.jsonl (must be very recent — within minutes):

   ls -la ~/.copilot/session-state/$SESSION/events.jsonl

3. Create a fake stale lock file for that session, with mtime backdated 3 weeks:

   echo $FAKE_PID > ~/.copilot/session-state/$SESSION/inuse.$FAKE_PID.lock
   touch -t 202604111200 ~/.copilot/session-state/$SESSION/inuse.$FAKE_PID.lock

4. From a separate terminal, run copilot --resume=$SESSION
5. Observe the warning: "This session was last active 3w ago and appears to be in use by another CLI or application. Resuming it here may cause conflicts."

In step 4, events.jsonl for the session was modified seconds before the launch, but the warning reports '3w ago' because it reads from the backdated lock file's mtime.

Expected behavior

The 'last active' timestamp in the warning should reflect actual session activity (e.g. events.jsonl mtime, or a session-level updated_at field) rather than the lock file's mtime. The lock file mtime is meaningful for detecting whether the lock itself is stale, but it is not a useful proxy for when the session was last edited.

Additional context

How I found this:

1. A previous --resume process (the deadlock in postToolUse hook deadlocks after write-permission request, process spins at 99% CPU and ignores SIGTERM #3084) had been holding a lock file from 21 April 2026 in this session's folder.
2. The current --resume process for the same session was active and writing to events.jsonl continuously.
3. On every fresh launch, I would get the 'last active 3w ago' warning even though I had just been using the session moments before.
4. After killing the deadlocked process, I tested the artificial repro above to confirm the cause: the warning reads the lock file's mtime, not session activity.

A separate observation about how 'go back' from this warning leaves a phantom lock will be filed as another issue.

Environment:

• macOS, Apple Silicon
• Copilot CLI 1.0.40 (Homebrew install)