docs(leetcode-26): update variable count and escape analysis in Go doc

Author: myoshi2891

Algorithm/TwoPointers/leetcode/26. Remove Duplicates from Sorted Array/Sonnet 5/Remove-Duplicates-from-Sorted-Array-Go.md

@@ -12,7 +12,7 @@
 
 - **制約分析**: LeetCodeの制約は`1 <= nums.length <= 3 * 10^4`程度であり、O(n)アルゴリズムであれば余裕を持って制限時間内に収まります。O(n log n)やO(n²)を使う必要は全くありません。
 - **最速手法**: ソート済みという性質を使ったTwo-Pointer（二重ポインタ）法がBig-O最適（O(n)）かつGo実装最適（追加ヒープアロケーション0回）の両方を満たします。
-- **メモリ最小化**: 新しいスライスや`map`を一切生成せず、`int`型のローカル変数1個だけで完結させます。プリアロケーションも不要（そもそも新しいスライスを作らないため）です。
+- **メモリ最小化**: 新しいスライスや`map`を一切生成せず、`int`型のローカル変数2個（`slow` と `fast`）だけで完結させます。プリアロケーションも不要（そもそも新しいスライスを作らないため）です。
 - **Go最適化**: 組み込み関数（`len()`）以外は特に標準ライブラリを使わず、シンプルなforループのみで実装します。
 
 ### 業務開発視点
@@ -26,7 +26,7 @@
 - **データ構造選択**: この問題は「順序ありでインデックスアクセスが必要」という性質を持つため、スライス`[]int`がそのまま最適です。`map`（キー検索）や`channel`（ゴルーチン間通信）は不要です。
 - **標準ライブラリ活用度**: 実は標準ライブラリの`slices.Compact`（Go 1.21+で追加）がまさにこの問題と同種の処理を行いますが、今回はアルゴリズムの内部動作を理解する教育的価値を重視し、手動でTwo-Pointerを実装します。
 - **並行処理適性**: 不適。前の要素の処理結果（`slow`ポインタの位置）が次の判定に依存する逐次処理のため、ゴルーチンによる並列化はできません（並列化すると`slow`の値が競合し、データ競合（Race Condition）を引き起こします）。
-- **エスケープ解析**: `slow`と`fast`はどちらも関数のスコープ内でのみ使われる`int`型のローカル変数であり、関数の外に参照が漏れることがないため、コンパイラはこれらをスタックに割り当てます（ヒープへの「逃げ」は発生しません）。`nums`自体は呼び出し元から渡されたスライスヘッダのコピーですが、内部のポインタが指す配列本体はすでにヒープ上（あるいは呼び出し元のスタック）にあり、今回新たにヒープアロケーションが発生することはありません。
+- **エスケープ解析**: `slow`と`fast`はどちらも関数のスコープ内でのみ使われる`int`型のローカル変数であり、通常はヒープへエスケープしません。ただし実際の割り当て（スタック配置やレジスタ割り当て）はGoコンパイラのエスケープ解析と最適化に依存します。`nums`自体は呼び出し元から渡されたスライスヘッダのコピーですが、内部のポインタが指す配列本体はすでにヒープ上（あるいは呼び出し元のスタック）にあり、今回新たにヒープアロケーションが発生することはありません。
 
 > 📖 **このセクションで登場した用語**
 >