`--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.

Start in internal/attachments/client.go by checking uploadPermissions and trace how the 404 is handled for READ and TRIAGE. Inspect the gh issue create help text for the existing attachment guidance, then verify whether the endpoint or CLI owns the restriction. Done means the permission behavior is resolved or clearly documented, and the help explains the requirement and Enterprise Server limitation.

Written by the indexing model from the issue text.