Feature Request: Enable agentic workflows to access issue/PR file attachments

## Problem

Agentic workflows triggered by issues cannot download file attachments (`.docx`, `.pdf`, `.xlsx`, `.pptx`, etc.) that users attach to issue bodies or comments. This is a significant limitation for workflows that need to process uploaded documents — for example, triaging issues that include specification documents, reviewing attached reports, or extracting data from uploaded spreadsheets.

### Current behavior

When a user attaches a file to a GitHub issue, the file is uploaded to a `user-attachments` URL such as:

```
https://github.com/user-attachments/assets//.docx
```

The agent cannot access these URLs. Attempts to download them via `curl`, `gh api`, or any authenticated HTTP request using `GITHUB_TOKEN`, fine-grained PATs, or GitHub App tokens all return **HTTP 404**.

This is a known GitHub platform limitation — the attachments API does not support programmatic download of issue/PR file attachments (see [cli/cli#9046](https://github.com/cli/cli/issues/9046), [community discussion #162417](https://github.com/orgs/community/discussions/162417), [community discussion #54551](https://github.com/orgs/community/discussions/54551)).

### Why this matters for agentic workflows

Agentic workflows are uniquely positioned to process unstructured documents attached to issues. Real-world use cases that are currently blocked include:

- **Document review workflows**: An issue is opened with a `.docx` spec attached → the agent reads the document, validates it against repo conventions, and comments with feedback.
- **Data extraction**: A `.xlsx` or `.csv` is attached to a bug report → the agent parses the data to reproduce or triage the issue.
- **Intake/onboarding automation**: Users submit requests by opening an issue with supporting documents attached → the agent processes the attachments and routes the request.
- **Compliance and audit**: Attached evidence files need to be read, catalogued, or cross-referenced by an automated workflow.

The fact that agents can read issue bodies, comments, labels, and repo files — but *not* the files users attach — creates a gap in what should be a natural workflow pattern.

## Proposed solution

Provide a mechanism for agentic workflows to access file attachments on the triggering issue or PR. Some possible approaches:

### Option A: Built-in safe-input or tool (preferred)

Add a built-in tool (e.g., `download-attachment`) or extend the GitHub MCP server toolset to support downloading attachments from issues/PRs. The agent would call something like:

```
download_attachment(issue_number, attachment_url) → local file path
```

This would use the workflow's `GITHUB_TOKEN` or configured PAT to authenticate and download the file into the agent's workspace.

### Option B: Expose attachments via the GitHub MCP server

Extend the `issues` toolset in the GitHub MCP server to return attachment metadata (filename, URL, size, mime type) alongside issue content, and provide an authenticated download capability. This would fit naturally into the existing `github:` tools configuration:

```yaml
tools:
github:
toolsets: [issues, attachments] # new toolset
```

### Option C: Pre-download attachments as a compile-time/runtime step

During workflow setup (before the agent runs), automatically detect attachment URLs in the triggering issue body and download them into the workspace (e.g., `/tmp/attachments/`). The agent would then access them as local files. This could be configured in frontmatter:

```yaml
on:
issues:
types: [opened]
attachments: true # pre-download attachments to workspace
```

## Workarounds (current, all have friction)

| Workaround | Limitation |
|---|---|
| Ask users to commit files to the repo instead of attaching | Changes user behavior; not always practical |
| Use an orphaned assets branch | Extra setup; requires contributor workflow change |
| Link to external storage (SharePoint, Drive) | Requires additional MCP server; breaks GitHub-native workflow |
| Parse issue body and `curl` the URL | Returns 404 — this is the core problem |

## Environment

- **gh-aw version**: 0.58.3
- **Repo visibility**: Private repos (not tested on public repos)

## Additional context

This feature would pair well with existing MCP servers like `markitdown` (for converting documents to markdown) or custom `safe-inputs` that process binary files. The missing piece is purely the *access* — once the file is in the workspace, the ecosystem already has tooling to handle it.