docs: README に意図伝達・導入順序・GDD・判断と定型の区別を戻し、今の構成と統合する

[yktsnet]

概要

公開範囲を絞った #63・#64 と、その後の書き直し（#67〜#70）で、このリポの設計思想の中心が README から抜けていた。「意図伝達」・導入順序・GDD と2つの駆動文書・判断と定型の区別は、リポのどこにも残っていなかった。今の Why → Design の流れと図は保ったまま、旧版（7e7c578・d64b908）の良かった記述を統合する。

変更

• 冒頭と Why: ボトルネックを「検証と意図伝達」の2つに戻す。意図伝達の段落（書かれていない条件をエージェントが推論で埋める）を足し、「注意し続ける人間を前提にしない」「人の仕事は約束の裁可へ移る」で締める
• Principles（新設）: 導入順序の5段、段の間の依存、最小構成は1〜3、を戻す
• Design: 5段と同じ順に並べ直す
  • 「作る前に型を決める」「読まれる場面ごとに知識を置く」「守る約束を先に裁可する」を足す
  • 判断と定型の区別、GDD、台帳の敷設・追従・範囲の一致・一望、立ち上げ期（PLAN/JUDGE）から Issue 駆動期への移行を書く
• 決める役と作る役を分ける: zsh 関数の一覧（issue-open / issue / issue-abort / issue-finish）を戻す。「複数の Issue を並行して走らせられる」を、new-issue の規則（機構上は並列にもできるが1本ずつ実装する）に合わせて直す
• Foundation（新設）: 道具を揃える・規則を配る・機密を出さない、の3節を Design から移す
• Skills（復活）: Principles の段ごとに並べた表を戻す
• Scope: 稼働側がほかに何を束ねているかを1文足す（役割名だけで書く）
• README.en.md: 同じ構成に合わせて更新する

検証手順

• README から張ったリンク先（skill・hooks/README.md・memory.nix・common.md・guarantees-index）が実在すること
• 書いた規則が各 skill の記述と食い違わないこと（new-issue の直列の規則、pr-workflow の手順5・6、guarantee-audit の台帳の規則、consolidate-rules の description）
• GitHub 上で Mermaid 図と表が崩れずに表示されること