`--attach` requires write access, so outside reporters cannot attach screenshots

### Describe the feature or problem you’d like to solve

First, thank you for shipping this. #13256 and the stack at #14186 closed a request that had been open in one form or another since #1895 in 2020, and the design is better than the workarounds it replaces — being able to write ordinary markdown against local paths and have those references rewritten on upload means a report drafted offline stays readable before it is ever posted. I am very glad to see it land.

One gap, from the read-only side of the fence.

`--attach` accepts a credential only when its permission on the target repository is `ADMIN`, `MAINTAIN` or `WRITE`:

```go
// uploadPermissions lists the repository permissions that can attach a file.
// The list matches api.Repository.ViewerCanPush, and it is measured against the
// upload endpoint: READ and TRIAGE get a 404.
var uploadPermissions = []string{"ADMIN", "MAINTAIN", "WRITE"}
```

— `internal/attachments/client.go`

That excludes the group that most often needs to attach a screenshot to an issue: the outside reporter, who has `READ`. I use `gh` to follow up on my own open issues, and `viewerPermission` is `READ` on every repository I track — this one included — so `--attach` is unavailable for all of them:

| repository | `viewerPermission` |
| --- | --- |
| `cli/cli` | `READ` |
| `openai/codex` | `READ` |
| `microsoft/vscode` | `READ` |
| `anthropics/claude-code` | `READ` |
| `tauri-apps/tray-icon` | `READ` |

Meanwhile the same account can drag a screenshot into a comment on any of those repositories through the web UI and it renders. That asymmetry is visible in this tracker: in #12960, drogers0 — `author_association: NONE` on this repository — posted a `github.com/user-attachments/assets/…` image scoped to `cli/cli`, using an extension that replicates the web upload flow with a browser session cookie. So the platform does permit a read-only user to create one of these assets. It is the token-authenticated path that refuses.

### Proposed solution

1. **If the `404` for `READ`/`TRIAGE` is a property of `POST /user-attachments/assets` rather than a CLI decision, say so** — here, and ideally on github/roadmap#1324, which describes the feature with no mention of a permission requirement. That tells people where the ask actually belongs, which is the same courtesy #12960 got when the blocker was the missing API.
2. **If the endpoint can serve a user who is permitted to comment on the repository, please allow that.** Permission to comment, rather than permission to push, is what gates the equivalent web-UI upload.
3. **Either way, document the requirement in the `--attach` help.** The long help for `gh issue create` covers the 50-file limit, the alt-text syntax and the partial-failure behaviour, but neither the permission requirement nor the GitHub Enterprise Server exclusion, so a read-only user meets both only as an error.

Point 3 stands on its own and is worth doing even if 1 and 2 are declined.

### Additional context

I have not run the preview build — the artifacts linked from #13256 expired on 25 August, and this has not shipped in a release yet (latest is 2.98.0 from 2026-08-20; the stack merged 2026-08-25). The above is read from the merged code on trunk, so please correct me if the released behaviour differs.

internal/attachments/client.go から始めて、uploadPermissions を確認し、READ と TRIAGE に対して 404 がどのように処理されるかを追跡します。既存の添付ファイルに関する案内について gh issue create のヘルプテキストを調べ、その制限を担っているのがエンドポイントか CLI かを確認します。完了とは、権限の動作が解決されるか明確に文書化され、ヘルプで要件と Enterprise Server の制限が説明されていることです。

索引モデルが issue の本文から書いたものです。