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

### 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`):
```bash
SESSION=
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):
```bash
ls -la ~/.copilot/session-state/$SESSION/events.jsonl
```
3. Create a fake stale lock file for that session, with mtime backdated 3 weeks:
```bash
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 #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)

Begin at the --resume warning path and inspect how session-state lock files and events.jsonl timestamps are read. Confirm the warning uses recent session activity rather than the lock mtime, then reproduce with the supplied stale-lock steps and verify the displayed duration.

Vom Indexierungsmodell aus dem Issue-Text verfasst.