'Go back' from 'session in use' warning leaves a phantom lock on the abandoned session's folder

[CianH]

Describe the bug

When the 'session in use by another CLI or application' warning fires on --resume and the user picks 'Go back', the CLI starts a new session — but it leaves an inuse.<PID>.lock file in the abandoned session's folder. That lock is not removed when the new session starts. As a result, a process that explicitly chose NOT to resume session A still holds a lock on session A.

If a third terminal then tries to resume session A, it will see the phantom lock and the 'session in use' warning — even though no process is actually editing session A apart from the legitimate one already on it.

Affected version

1.0.40 (reproduced just now)

Steps to reproduce the behavior

1. In Terminal 1, run copilot --resume=<session-A-id> and use the session normally so its inuse.<PID1>.lock exists. Leave it running.
2. In Terminal 2, plant a fake stale lock for session A so Terminal 3's resume attempt will trigger the in-use warning:

   FAKE_PID=88776
   ps -p $FAKE_PID > /dev/null && echo "choose another" || echo OK
   echo $FAKE_PID > ~/.copilot/session-state/<session-A-id>/inuse.$FAKE_PID.lock
   touch -t 202604111200 ~/.copilot/session-state/<session-A-id>/inuse.$FAKE_PID.lock

3. In Terminal 3, run copilot --resume=<session-A-id>.
4. The 'session in use' warning fires. Choose Go back.
5. Terminal 3 drops into a brand new empty session (a different session ID, e.g. 17b762de-...). Confirm the new session ID by checking ~/.copilot/session-state/ for the most recently created folder. (Note: the fake stale lock from step 2 IS cleaned up here — 1.0.40 correctly detects PIDs that are no longer running.)
6. Inspect locks held by Terminal 3's PID (call it PID3):

   find ~/.copilot/session-state -name "inuse.$(pgrep -f \"copilot --resume\" | tail -1).lock"

7. Observe: PID3 holds a lock in BOTH session A's folder AND its own new session's folder. Both inuse files reference the same live PID3.

Expected behavior

When the user picks 'Go back' from the 'session in use' warning, the CLI should release any lock it took on the abandoned session's folder before starting a new session. A process that did not resume session A should not hold session A's lock.

Additional context

Concrete example from the repro:

$ find ~/.copilot/session-state -name 'inuse.65690.lock'
/Users/USER/.copilot/session-state/<session-A-id>/inuse.65690.lock           # phantom — process never resumed this session
/Users/USER/.copilot/session-state/<session-B-id>/inuse.65690.lock           # legitimate — the new empty session it dropped into

PID 65690 is alive and running copilot --resume=<session-A-id> per its command line — but the actual session it is editing is <session-B-id>. The lock in session A's folder will not be cleaned up until 65690 exits.

Practical impact: after using 'Go back', the original session A is now flagged as 'in use' to any other process that tries to resume it, even though only the legitimate user of session A (Terminal 1) is actually editing it.

Combined with #3085, the resulting warning will also display a misleading 'last active' timestamp.

Environment:

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