"Stacked PRs are not enabled for this repository" shown when the real problem is repository access (wrong active gh account)

## What happened

Every `gh stack` command against our org repository failed with:

> ⚠ Stacked PRs are not enabled for this repository

…while the repository visibly had stacks in active use (colleagues' stacks in the PR list, and creating one through the web UI worked fine). We spent a good while chasing repository settings and extension versions before the actual cause surfaced: `gh` had two logged-in accounts in the keyring, and the **active** account had no access to the repository. `gh auth switch` to the right account fixed everything instantly:

```
$ gh auth status # two accounts; active one lacks access to the repo
$ gh api repos///stacks # → 404 for the active account, 200 for the other
$ gh stack submit --auto # → "Stacked PRs are not enabled for this repository"
$ gh auth switch -u && gh stack submit --auto # → works, stack created
```

## Why the message misleads

The extension maps every stacks API 404 to "feature not enabled" (`warnStacksUnavailable` in `cmd/utils.go`, behind all of its call sites). But observed behavior of the list endpoint on github.com says that interpretation is usually backwards — enablement is expressed by the array, and the 404 is about repository visibility:

| Situation | `GET /repos/{owner}/{repo}/stacks` |
| --- | --- |
| Readable repository, stacks in use | `200`, populated array |
| Readable repository, no stacks | `200`, `[]` |
| Repository not visible to the token (private without access, or nonexistent) | `404`, generic `{"message": "Not Found", …}` |

The 404 body is GitHub's deliberately anonymized not-found (private repositories are indistinguishable from nonexistent ones), so the response carries nothing that could be parsed to tell the cases apart — the only way to disambiguate is a second request.

## Proposed fix

Probe repository readability when a stacks API call 404s (`GET /repos/{owner}/{repo}`): if the repository itself is not readable, report the access problem and point at `gh auth status`; only when the repository is readable keep the existing not-enabled message (as the fallback for deployments that gate the feature).

I have this implemented, tested (`go build ./...`, `go test -race -count=1 ./...` green, plus new coverage for both messages), and pushed — diff here:

https://github.com/github/gh-stack/compare/main...fix8ing:gh-stack:fix/404-warning-names-account-access

It adds `ClientOps.RepoAccessible` (REST `GET /repos/{owner}/{repo}` on the live client, default-accessible mock arm) and routes the single shared helper — renamed `warnStacks404`, since it no longer asserts one interpretation — through the probe. I could not open a PR directly (the org rejects PR creation from my token), so linking the branch here instead; happy to open it properly if you enable that, or feel free to take the diff as-is.