openspec: упразднена спека toolchain

- Инструментарий проекта спеками не нормируется: capability toolchain удалена,
  норму шага сверки версий Go держат его проверки в scripts.
- Перечень capability в архитектуре и ревью сокращён до четырёх, решение
  ADR-2026-08-12-spec-norms-build-toolchain помечено устаревшим.

docs/conventions/go-linters.md

@@ -36,12 +36,12 @@ Go-проект как есть. Своё здесь — перечень пра
 - **настройка конвейера ревью, вопросы по темам и журнал дефектов** —
   [../review.md](../review.md). Перечень ниже говорит этим вопросам, чего
   спрашивать уже не нужно;
-- **поведение сервиса** — нормативные спеки `openspec/specs/`. У шага сверки
-  версий Go поведение нормировано отдельно, спекой
-  [toolchain](../../openspec/specs/toolchain/spec.md): это единственная проверка
-  проекта, у которой есть своя capability, и потому единственная, чьи сценарии
-  проверяются построчно (`scripts/check_go_version_test.go`). Второй самодельный
-  шаг — `migrations` — нормы не имеет: он проверен мутацией на трёх исходах
+- **поведение сервиса** — нормативные спеки `openspec/specs/`. Шаги набора
+  проверок туда не входят: инструментарий спеками не нормируется, и спека
+  `toolchain`, заведённая под шаг сверки версий Go, упразднена 2026-08-13. Норму
+  этого шага держат его собственные проверки — двадцать сценариев в
+  `scripts/check_go_version_test.go`, и другого дома у неё нет. Второй самодельный
+  шаг — `migrations` — не проверен и ими: он прогнан мутацией на трёх исходах
   (переписанный шаг, пустой каталог, чистое дерево), но регрессионных проверок у
   него нет, и дрейф его собственного шаблона имени никто не поймает. Владелец
   решил 2026-08-13 оставить это как есть: проверка над проверкой даёт много
@@ -147,7 +147,7 @@ Go-проект как есть. Своё здесь — перечень пра
 | Правило | Где механизировано |
 | --- | --- |
 | Проверка судит ответ по готовому ответу (`Result()`), а не по живой карте заголовков обработчика | `.golangci.yml` → `forbidigo` с `analyze-types`, находки только в `*_test.go`. Судит по типу приёмника (`httptest.ResponseRecorder`), поэтому ловит любую форму: цепочкой, через переменную, по индексу карты, обходом, полем `HeaderMap`. Остаётся ревью проверка, идущая мимо recorder — через свой `http.ResponseWriter` |
-| Каждый сценарий нормы шага сверки версий проверен мутацией, а не памятью | `scripts/check_go_version_test.go` — 20 сценариев спеки `toolchain` плюс два свойства самого шага: исход не зависит от установленного `go`, и шаг не зовёт ни `go`, ни `docker`, ни сеть |
+| Каждый сценарий нормы шага сверки версий проверен мутацией, а не памятью | `scripts/check_go_version_test.go` — 20 сценариев шага плюс два его свойства: исход не зависит от установленного `go`, и шаг не зовёт ни `go`, ни `docker`, ни сеть |
 | Форма утверждения в проверках: «ожидалось» и «получено» не перепутаны местами, отказ судится `NoError`, а не `Nil`, `require` не зовут из горутины | `.golangci.yml` → `testifylint` |
 | Одновременный доступ проверен детектором, а не чтением кода | `Taskfile.yml` → шаг `tests` (`go test -race ./...`). Общее у воркеров — счётчики метрик, логгер и клиент бота; захват задачи в гонку не входит, он по построению её не даёт (одно состояние на воркер) — см. «Типовые ложноположительные» в [../review.md](../review.md). Что делает шаг без компилятора C и каким кодом краснеет — [CLAUDE.md](../../CLAUDE.md), «Гейт» |
 | Строчное подавление называет линтер и причину, а протухшее краснеет | `.golangci.yml` → `nolintlint` (`require-explanation`, `require-specific`, `allow-unused: false`) |