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_

Commencez par retracer où sont placées les données dérivées de xcodebuild sous ~/.copilot/session-state//files/ et comment /session prune et /session delete gèrent ces chemins. Consultez la documentation de session-state concernant events.jsonl et workspace.yaml. Le travail est considéré comme terminé lorsque les données dérivées utilisent l’emplacement standard de Xcode ou un cache documenté avec nettoyage, et que les utilisateurs peuvent récupérer l’espace occupé par les données existantes via les commandes de session documentées.

Rédigé par le modèle d'indexation à partir du texte de l'issue.