chore: Markdownのインデント幅を4に固定し、リストの継続行をスペース4つに揃える

継続行がスペース2つだと、VS Codeがインデント幅を2と自動判定する。
.vscode/settings.json でMarkdownの自動判定を切って幅4に固定し、
既存の継続行もリストの記号から4つ下げた位置に揃える。
変更したファイルに markdownlint --fix をかけた分(journalのURL囲みと空行)も含む。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VbfgHT848s3JbuFw8MKFF8

journal/2026-09-24-hst-layer-scope.md

@@ -13,7 +13,7 @@
 ## 案の比較
 
 | 論点 | 当初の提案(人との議論) | Claude | Codex | 採用 |
-|---|---|---|---|---|
+| --- | --- | --- | --- | --- |
 | 名前 | SYS | HOST/HST | SYS → 最終的にHOST/HSTに同意 | HST |
 | 識別子 | WIN-JAP (OS×言語) | OS×配列の構造 | OS×配列×入力方式+プロファイル名 | OS×配列(+入力方式) |
 | 範囲 | OS・言語ごとのキーの振る舞い・表示 | ホストの解釈の記述 | 意図を環境ごとの出力に変換、まで候補 → 最終的に「対応関係を提供、変更はしない」 | 記述のみ |
@@ -24,12 +24,12 @@
 
 - SYSは、HIDのSystem Control用途ページ(電源・スリープ)や「システム設定全般」と紛らわしい。hostはHIDでキーボードの接続相手を指す用語で、QMKも「host keyboard layout」と呼ぶ。
 - 言語は軸として誤り: 日本語Windowsで英語配列を使える。MacではUS/JISが入力ソースとキーボード種別で決まる。XKBはlayout/variant/optionsの3要素。
-  「英語」にもUS・UKがある。`JAP` はISOコードでもない(ja/jpn)。
+    「英語」にもUS・UKがある。`JAP` はISOコードでもない(ja/jpn)。
 - 逆引きをプロファイルに持たせない理由: (1) 順方向の表から導けるので二重管理になる。
-  (2) 候補がファームウェアの機能に依存する。例: US刻印+JISホストでShiftの組が合わないキーにはKey Overrideが要る。HSTにQMKの知識が混ざる。
+    (2) 候補がファームウェアの機能に依存する。例: US刻印+JISホストでShiftの組が合わないキーにはKey Overrideが要る。HSTにQMKの知識が混ざる。
 - Codexの指摘で採用したもの: 表示の切り替えと送信内容の変更を混ぜない。知らない動作を「使えない」と扱わない(対応可否を3値にする)。OS設定への依存は記述する。
 - MAPの正本をキーコードにする理由の修正: Claudeは当初「VIAでは実機にキーコードしか残らず、意図を復元できないので、キーコードでなければならない」とした。
-  Codexが、意図をプロジェクト側に残す設計も可能で、難しくなるのは実機で変更された値の取り込みだけだと反論し、これが正しい。
-  採用する理由は「実機との往復を単純に保てるから」とする。
+    Codexが、意図をプロジェクト側に残す設計も可能で、難しくなるのは実機で変更された値の取り込みだけだと反論し、これが正しい。
+    採用する理由は「実機との往復を単純に保てるから」とする。
 - 「コピー」のような操作の辞書は、アプリやユーザー設定まで相手が広がるので対象外。
 - 未採用のアイデア: キートップの刻印生成にHSTを使う(PHYのラベルへ流す)。検討していないので仕様には書かない。