docs: stop describing the feature form as sharing the bug form's fields (#1844)

Round-4 Copilot nits, and it was right three times over — I had described
"client, version line, transport" as the required set for *both* forms in
CONTRIBUTING.md, AGENTS.md, and the config.yml header. The feature form has
neither a version-line dropdown nor a transport field, and cannot have the
first: v1 takes security fixes only, so a feature request is v2 by
construction.

Each of the three now distinguishes the two forms rather than generalizing
from the bug form.

Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: cliffhall

.github/ISSUE_TEMPLATE/config.yml

@@ -1,7 +1,8 @@
 # Issue chooser configuration.
 #
-# Blank issues are disabled so every report lands in a form with the fields
-# triage actually needs (client, version line, transport).
+# Blank issues are disabled so every report lands in a form. The bug form
+# requires the facts triage needs first (client, version line, transport); the
+# feature form requires the client and a problem statement, and is v2-only.
 #
 # Security reports are deliberately a *contact link* rather than a template:
 # a template would still open a public issue, which is exactly what a

AGENTS.md

@@ -120,7 +120,7 @@ If you've already built a change locally, share the **prompt** you used and scre
 
 **This applies to org members with write access too, not just outside contributors.** Having permission to push a branch is not authorization to open a PR. Pull requests against this repo are opened by the **repo maintainers** only. Anyone else — including organization members whose write access makes it technically possible — opens a **detailed issue** instead, and a maintainer takes it from there. A detailed issue means: the problem, how to reproduce it, the behavior you expected, and — if you've already prototyped a fix — the prompt you used and any screenshots, rather than a diff.
 
-**Issues are filed through the forms in [`.github/ISSUE_TEMPLATE/`](./.github/ISSUE_TEMPLATE) — blank issues are disabled.** GitHub serves the chooser from the **default branch** only, so a form edited here on `v2/main` has no effect on the live chooser until the next milestone merge into `main` — and it cannot be previewed before then, which is why the schema notes below matter. There are two forms, **Bug report** (`1-bug_report.yml`, auto-labels `bug`) and **Feature request** (`2-feature_request.yml`, auto-labels `enhancement`); `config.yml` holds the chooser's contact links. Neither form applies a `v1`/`v2` label — the version line is a required *dropdown*, since GitHub can't map a form answer to a label, so a maintainer still applies the version label at triage per [Label by version](#issue-driven-work-style). **There is deliberately no security template**: a vulnerability report must not open a public issue, so the chooser routes it to the private advisory form as a contact link instead (see [`SECURITY.md`](./SECURITY.md)). When adding or changing a form, validate it against GitHub's issue-forms schema (`markdown` blocks take no `id` and no `validations`; `checkboxes` mark `required` per option, not under `validations`).
+**Issues are filed through the forms in [`.github/ISSUE_TEMPLATE/`](./.github/ISSUE_TEMPLATE) — blank issues are disabled.** GitHub serves the chooser from the **default branch** only, so a form edited here on `v2/main` has no effect on the live chooser until the next milestone merge into `main` — and it cannot be previewed before then, which is why the schema notes below matter. There are two forms, **Bug report** (`1-bug_report.yml`, auto-labels `bug`) and **Feature request** (`2-feature_request.yml`, auto-labels `enhancement`); `config.yml` holds the chooser's contact links. Neither form applies a `v1`/`v2` label, because GitHub can't map a form answer to a label — `labels:` is static. The **bug** form therefore carries a required version-line *dropdown* and a maintainer applies the matching label at triage per [Label by version](#issue-driven-work-style); the **feature** form has no such dropdown, since v1 takes security fixes only and cannot receive a feature, so it states up front that it targets v2 and is always labeled `v2`. **There is deliberately no security template**: a vulnerability report must not open a public issue, so the chooser routes it to the private advisory form as a contact link instead (see [`SECURITY.md`](./SECURITY.md)). When adding or changing a form, validate it against GitHub's issue-forms schema (`markdown` blocks take no `id` and no `validations`; `checkboxes` mark `required` per option, not under `validations`).
 
 **Every PR must reference an issue. No exceptions, regardless of who opens it.** The PR body's first line is `Closes #<ISSUE_NUMBER>` (see the [Issue-driven Work Style](#issue-driven-work-style) rules below). A PR with no linked issue has no board card, so the work is invisible to the project board and untracked — if you're about to open one and there's no issue yet, create the issue first. This holds for a maintainer's own one-line fix as much as for a feature.
 

CONTRIBUTING.md

@@ -64,8 +64,10 @@ and implementation.
 
 [**New issue**](https://github.com/modelcontextprotocol/inspector/issues/new/choose)
 offers a **Bug report** and a **Feature request** form. Blank issues are
-disabled, so pick one of the two — the required fields (which client, which
-version line, which transport) are exactly the facts triage needs first.
+disabled, so pick one of the two. The bug form requires the facts triage needs
+first — which client, which version line, which transport; the feature form
+asks for the client and the problem you are trying to solve, and targets v2
+only.
 (GitHub serves the chooser from the repository's **default branch**, so what
 you see when filing is whatever has reached `main`; a form added on `v2/main`
 appears at the next milestone merge.) The same chooser links out to the private