Goose sessions file duplicate GitHub issues when `gh issue create --type` fails after creating the issue

**Describe the bug**

Goose sessions following the `AGENTS.md` contribution guidance ("Structure new issues on the matching template … and set the issue type (e.g. Bug, Feature)") run `gh issue create --type Bug`. Because `gh issue create --type` is **not atomic** — it creates the issue first, then sets the type via a separate `UpdateIssueIssueType` GraphQL mutation — any account without triage permission gets an exit-code-1 failure *after the issue already exists*. The agent interprets the non-zero exit as "nothing was created" and retries, filing an identical second issue.

This happened twice:

- **#11678 + #11679** (2026-08-30, session `20260830_123`) — SSE-keepalive stall report
- **#11699 + #11700** (2026-08-31, session `20260831_286`) — opencode_go GLM model list report

In both cases the pairs are byte-identical, created seconds apart, and the earlier one had to be closed as a duplicate. The failing tool result in both sessions was:

```
GraphQL: SynthLuvr does not have the correct permissions to execute `UpdateIssueIssueType` (updateIssueIssueType)
Command exited with code 1
```

The root enabler is ambiguous: `gh` created the issue (#11699) and only the type-set step failed, but the command exited 1 without printing the created URL, so the retry (without `--type`) created #11700.

---

**To Reproduce**

1. Run a goose session configured with a GitHub account that is a contributor on `aaif-goose/goose` but lacks triage permission (cannot set issue types).
2. Ask it to file a bug report per `AGENTS.md` (which directs setting the issue type).
3. The session runs `gh issue create --repo aaif-goose/goose --type Bug --title … --body-file …`.
4. gh creates the issue, then fails on the type mutation → "Command exited with code 1".
5. The session retries (typically without `--type`) without first checking whether the first attempt created anything → second, identical issue.

---

**Expected behavior**

- When a `gh issue create` exits non-zero, goose sessions should **verify whether the issue was actually created** (e.g. `gh issue list --search ""` / `gh issue view`) before retrying a non-idempotent create. A failed create command is not proof nothing was created.
- `AGENTS.md` should warn that `gh issue create --type` is non-atomic and that the type mutation can fail *after* the issue is created, particularly for non-triage contributors.

---

**Screenshots**

N/A (reproducible from session transcripts in `~/.local/share/goose/sessions/sessions.db`; full sequence recorded in sessions `20260830_123` and `20260831_286`).

---

**Please provide the following information**

- **OS & Arch:** Linux x86_64
- **Interface:** CLI
- **Version:** 1.48.0
- **Extensions enabled:** n/a
- **Provider & Model:** opencode_go – glm-5.3 (sessions that reproduced it)

---

**Additional context**

- Upstream root cause is tracked in **cli/cli#13804** ("`gh issue create` errors after successful creation when issue type can't be set"), with fix PR **cli/cli#13899** ("Warn instead of failing when issue fields can't be set") — once merged, gh will print the created URL and exit 0, removing the ambiguity. This issue tracks the goose-side mitigation for sessions running older `gh` and for the retry behavior generally.
- Suggested goose-side fixes (docs/guidance scale, no Rust changes needed — the retry decision is LLM behavior in the agent loop):
- Reword the `AGENTS.md` filing instruction: drop or gate `--type` for non-triage accounts (types can be assigned during triage), and mandate verify-before-retry on any failed `gh issue create`.
- Optionally add a `workflow_recipes/` issue-filing flow (mirroring `release_risk_check`) that encodes the pre-check.
- Meta note: filing this very issue with `--type` from a contributor account reproduces the same partial-failure path — recommend filing without `--type` (the draft you are reading contains only template frontmatter for the repo's own workflow).

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).