Xcode DerivedData written into ~/.copilot/session-state accumulates indefinitely — please use a standard location

### Describe the bug

When Copilot CLI builds or tests Xcode projects, it writes Xcode derived data inside its own session-state directory rather than the standard Xcode location. I've found it in two layouts:

- ~/.copilot/session-state//files/apptests-deriveddata/
- ~/.copilot/session-state//files/diagnostics/DerivedData/

These contain the usual derived data content (Build/, CompilationCache.noindex/, SourcePackages/, ModuleCache.noindex/, Info.plist, etc.). On my machine a single session's DerivedData folder had grown to over 20 GB. And I had instances of both paths listed above, so 40GB+ used by stale Copilot sessions.

Why this is a problem

1. Silent, unbounded disk growth. Derived data is large and regenerable, but it's stored per-session with no apparent retention policy, so it accumulates until the user manually prunes sessions.
2. Hidden from every existing cleanup path. Because it lives in a hidden dot-folder rather than ~/Library/Developer/Xcode/DerivedData, it's invisible to Xcode's own cache management, to disk-space tools, and to Xcode cleanup utilities (e.g. DevCleaner). Users have no reason to suspect their vanishing disk space is under ~/.copilot.
3. Not documented. The session-state docs describe events.jsonl / workspace.yaml, but I couldn't find any mention that multi-gigabyte build artefacts are also stored there, and the location within a session varies.

Suggested behaviour

- Prefer the platform-standard location (~/Library/Developer/Xcode/DerivedData) as other CLI coding agents do (Claude Code and Codex CLI don't redirect xcodebuild output), so existing Xcode tooling and cleaners manage it; or
- if session isolation is required, use a documented, dedicated cache location (e.g. ~/Library/Caches/ on macOS, marked as excluded from Time Machine) with automatic cleanup — deleted when the session ends or is pruned, and/or subject to a retention/size cap.
- At minimum, document that derived data is stored under session-state and that /session prune / /session delete is the way to reclaim it.

Environment

- Copilot CLI version: 1.0.70
- OS: macOS 26.5.1
- Xcode: 26.2

### Affected version

1.0.70

### Steps to reproduce the behavior

1. Use Copilot CLI in an iOS/macOS project and ask it to build or run tests.
2. Inspect ~/.copilot/session-state//files/ — derived data appears in one of the layouts above.
3. Repeat across sessions/days; the folders are never cleaned up.

### Expected behavior

- Prefer the platform-standard location (~/Library/Developer/Xcode/DerivedData) as other CLI coding agents do (Claude Code and Codex CLI don't redirect xcodebuild output), so existing Xcode tooling and cleaners manage it; or
- if session isolation is required, use a documented, dedicated cache location (e.g. ~/Library/Caches/ on macOS, marked as excluded from Time Machine) with automatic cleanup — deleted when the session ends or is pruned, and/or subject to a retention/size cap. Or a temporary location like /tmp/build.
- At minimum, document that derived data is stored under session-state and that /session prune / /session delete is the way to reclaim it.

### Additional context

_No response_

Start by tracing where xcodebuild-derived data is placed under ~/.copilot/session-state//files/ and how /session prune and /session delete handle those paths. Check the session-state documentation around events.jsonl and workspace.yaml. Done means derived data uses the standard Xcode location or a documented cache with cleanup, and users can reclaim existing data through the documented session commands.

Written by the indexing model from the issue text.