Viewing local GIF files crashes/ruins the CLI session

## Bug Description

Viewing (or referencing) a local GIF file in a Copilot CLI session causes the session to become unresponsive or enter an unrecoverable error state.

## Steps to Reproduce

1. Start a Copilot CLI session
2. Ask Copilot to view or reference a local `.gif` file (e.g. `view` tool on a GIF attachment)
3. The session becomes stuck — high CPU usage, excessive memory consumption, and no further interaction is possible

## Observed Behavior

- The `view` tool attempts to base64-encode the entire GIF file (including all animation frames) and inject it into the conversation context
- For animated GIFs, this produces a massive base64 payload that either:
- Floods the context window, leaving no room for model reasoning
- Triggers an error loop that the session cannot recover from
- The stuck process consumes ~36% CPU and ~957 MB RAM indefinitely
- The only recovery is to `kill` the process manually

## Expected Behavior

- The CLI should detect animated GIF files and either:
- Extract and display only the first frame
- Return file metadata (size, dimensions, frame count) without dumping the full base64 payload
- Reject the file with a helpful message (e.g. "Animated GIFs are not supported, use a static image format")
- Large image files in general should have a size guard to prevent context flooding

## Environment

- **Copilot CLI version:** 1.0.10 (confirmed), likely also affects 1.0.15
- **OS:** macOS (Darwin, Apple Silicon)
- **GIF file sizes tested:** ~240 KB and larger (wiki attachments)

## Workarounds

- Avoid using `view` on `.gif` files
- Use `ls -lh file.gif` or `file file.gif` to inspect GIF files safely
- Convert GIFs to single-frame PNG before viewing: `ffmpeg -i file.gif -frames:v 1 frame.png`