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_

首先追踪 xcodebuild 派生的数据被放置在 ~/.copilot/session-state//files/ 下的什么位置，以及 /session prune 和 /session delete 如何处理这些路径。检查 session-state 中关于 events.jsonl 和 workspace.yaml 的文档。当派生数据使用标准的 Xcode 位置或带有清理机制的已记录缓存，并且用户可以通过已记录的会话命令回收现有数据时，即视为完成。

由索引模型根据 Issue 内容生成。