Image attachment downloads have no size limit and buffer untrusted files fully in memory

## Summary

The GitHub image downloader accepts the entire response body with ``arrayBuffer()`` and writes it to disk without checking ``Content-Length``, enforcing a maximum size, or streaming with a bounded buffer.

## Reproduction

1. Process an issue or pull request containing one or more GitHub user-attachment images.
2. Make a signed attachment response advertise or return a very large body, or include many large attachments in the context.
3. Observe that ``downloadCommentImages`` reads each complete body into memory before it can decide whether to save it.

A deterministic unit test can mock ``response.arrayBuffer()`` to return a body larger than the configured maximum and assert that it is rejected before being written.

## Expected behavior

Image downloads should have a documented maximum size and reject oversized responses before consuming unbounded memory or disk space. A single oversized attachment should be skipped without preventing the rest of the context from being processed.

## Actual behavior

At ``src/github/utils/image-downloader.ts:244-267``, the code awaits ``fetch``, then calls ``arrayBuffer()`` for the complete response and writes the resulting buffer. No response-size check or streaming limit exists.

## Why this matters

Attachment URLs originate in untrusted issue, PR, and comment content. A large or repeated set of attachments can exhaust the runner's memory or temporary disk space during context preparation, causing the action to fail before Claude starts.

## Suggested fix

Enforce a maximum using ``Content-Length`` when available and a bounded streaming reader for responses without that header. Add tests for both an oversized declared length and a stream that exceeds the limit.

## Related

This is separate from #702 and #1351, which concern image MIME detection, #1588, which concerns asset matching, and #1623, which adds a time bound for stalled downloads.