tests(gates): the issue-label-map fixture pins no near-miss negatives

### The gap `scripts/testdata/issue-titles.tsv` is the fixture that pins what the issue labeller's cheap rule pass classifies (#393). Its header states the intent plainly: > `'-'` means the rule pass must NOT classify it — those titles are the ones > that fall through to the model pass, and that fall-through is just as much a > behaviour worth pinning as a match is. The negatives it carries are all *prose* titles — real issue titles with no conventional-commit prefix at all. What it has no case for is a **near miss**: a title that looks like a type prefix but is not one the map knows. The map (`.github/issue-labeler.yml`) recognises `fix`, `feat`/`feature`/`perf`, `docs`/`doc`, `refactor`, `ci`/`build`/`coverage`/`release`, and `test`/`tests`. So all of these must fall through — and nothing asserts that any of them do: - `chore: bump the year in the licence headers` - `style: gofmt the harness` - `revert: "feat(plugin): derive the v4 client-id from the MAC"` - `docsite: the versioned docs dropdown shows only latest` - `feature-flag: gate the ipvlan path` The last two are the interesting ones. `docsite:` and `feature-flag:` start with the literal text of a known prefix; whether they match depends on details of the anchoring that are currently only implied by reading the regex. ### Why it matters A broken pattern here fails nothing at runtime. It quietly pushes issues onto the model pass and mislabels nothing visibly — which is exactly why the gate exists. A rule that started matching `chore:` as `documentation` would be invisible without a fixture case. ### The task 1. Add near-miss negatives to `scripts/testdata/issue-titles.tsv` under the existing "must fall through to the model pass" section. 2. Run the gate and confirm it still passes: ```sh bash scripts/check-issue-label-map.sh ``` 3. If any case does *not* fall through, that is a finding, not something to delete — say so in the PR and leave the case in, failing, so the discussion has evidence. Point 3 is the repo's rule and it is not a formality: a test that only passes once you weaken it is a bug report. ### Why this is a good first issue One data file, one command to verify, and the gate tells you immediately whether you are right. No Go, no Docker, no privileges. ### Getting started Branch off `dev` (never `main`), name it `tests/`, and open a PR against `dev`. See the Contributing section of the README.