chore: bump the pinned Go toolchain to 1.26.8 and fail on fixable stdlib CVEs

[kwrkb]

#21 で決定した引き上げ方針の初回適用です。

なぜ上げるのか

固定は stdlib を凍結するので、Go 本家のセキュリティ修正が届かなくなります。これが固定の唯一のコストで、既に未払いになっていました。1.26.5 には到達可能な stdlib 脆弱性が3件あります。

ID	パッケージ	修正版	到達経路
GO-2026-6218	net/url	go1.26.6	—
GO-2026-6090	crypto/tls	go1.26.6	ServeStdio → tls.Conn.Read
GO-2026-5972	encoding/asn1	go1.26.6	ServeStdio → asn1.Unmarshal

3件とも govulncheck が「呼び出しに到達する」と判定したもので、理論上の話ではありません。1.26.8 では No vulnerabilities found になります。同一マイナー内のパッチ引き上げなので言語変更は無く、再ビルドのみで済みます。

なぜ気づけなかったのか（＝一緒に直すもの）

CI は毎PR govulncheck を走らせていましたが、stdlib の指摘を一律 ::warning:: で握り潰す設計でした。警告は誰も読まないため、固定版は3パッチ分の既知 CVE を抱えたまま放置されていました。

許容条件を絞ります。Fixed in: のバージョンが固定中のマイナーと一致するなら、パッチ引き上げだけで直る＝据え置く理由が無いので fail（対処法をエラーメッセージに明示）。マイナー跨ぎが必要なものだけ warning のまま許容します。7ジョブすべてに適用。

方針の明文化

CLAUDE.md に「Go バージョンの引き上げ方針」を追加しました（条件4つ／マイナー移行は EOL 直前まで据え置き／据え置き根拠は1回の引き上げ＝21バイナリ再ビルド ≒ 157MB の新規 blob）。AGENTS.md からそこを参照し、.go-version の独断書き換えを禁止しています。

go.mod の go ディレクティブは言語の下限であって固定版とは別の軸なので、意図的に動かしていません。

検証

• govulncheck: 1.26.5 で3件到達可能 → 1.26.8 で No vulnerabilities found。
• ゲートのロジック: workflow から govulncheck ステップを抽出してローカル実行し、3ケースを確認。pin=1.26.5（同マイナー内で直る）→ exit 1、pin=1.26.8（脆弱性なし）→ exit 0、修正がマイナー跨ぎ（Fixed in: net/http@go1.27.2）→ exit 0 + warning。
• テスト: GOTOOLCHAIN=go1.26.8 で7モジュール全ての go vet / go test -count=1 が pass。
• 決定論性: 連続2回のビルドが bit-identical。
• スモークテスト: 1.26.8 で焼いた settings-advisor バイナリを実行し、feat(settings-advisor): enhance scan detection and adopt traits-driven model selection #20 の修正（.env.production.example で HasEnv を立てない）が配布物に入っていることを確認。

注意

21バイナリすべてが差分になります（.go-version 1行 + バイナリ21本 + ドキュメント3本 + workflow）。これは想定どおりで、ツールチェーンを上げれば全バイナリが変わるためです。

🤖 Generated with Claude Code