改造点 20260703：無限鍵盤を「通常鍵盤と全く同じ描画」に統一 ＋ 停止時視点リセットの戻し先修正
・[FIX][独自][実験的] 無限鍵盤：境界の黒鍵（note126 F#9 など）の位置ズレを修正。
→原因：ジオメトリ生成の黒鍵位置補正に「最後の黒鍵(note126)は中央寄せ」「表示範囲の
先頭/末尾で取り残される黒鍵は中央寄せ」という端専用の特例があり、無限鍵盤では端が
本当の端ではない（両方向に拡張が続く）のに F#9 等が中央寄せされ、内側の同じ音の黒鍵
（本来の F# シフト）とズレていた。無限鍵盤時はこれら端の中央寄せを行わないようゲート。
→ F#9 の中心オフセットが内側 F#8 と完全一致（実測 -0.034 = -0.034）し、拡張と揃う。
・[FIX][独自] 手動停止(Stop/ESC)時の視点リセットの戻し先を「保存済み視点」に変更。
→従来はハードコードの既定視点(SetDefaultViewpoint)に戻していたため、Auto save viewpoint で
作った視点や、OFF 時のユーザー視点まで毎回“初期位置”に飛ばされていた。
ロード時と同じ手順で conf の "Viewpoint-"（保存が無ければ既定）へ戻すように統一
(_ResetViewpointToSaved)。Auto save viewpoint ON なら直前保存で現在位置＝保存視点となり
実質そのまま維持、OFF でもユーザーが保存した視点へ戻る。
・[FIX][独自][実験的] 無限鍵盤：拡張オクターブを別バッファ／別 Draw で描くのをやめ、
各キーボード自身の頂点・インデックスバッファの「末尾に連結」して、通常の 0-127 と
“同じ 1 回の Draw・同じワールド行列”でまとめて描くようにした。
→拡張部は通常鍵盤と完全に同一の描画経路を通るため、別 Draw 同士の深度競合が原理的に
なくなり、環境（GPU）によって拡張部の黒鍵が白鍵に覆われる不具合が出なくなる。
・[FIX][独自][実験的] 無限鍵盤：インデックスの送信順を「真のノート順」に並べ替えた
＝［note0未満の拡張］→［通常 0-127］→［note128以降の拡張］。
→原因：鍵盤キーは conf で半透明(WhiteKeyColor/BlackKeyColor の alpha<255)にでき、
鍵盤はブレンド有効＋深度書き込みONで描かれる。拡張部をバッファ末尾に足すと、
note0 未満の拡張が通常鍵盤より“後”に描かれ（＝順序が逆）、半透明＋同一深度の境界で
「後に描いた面が勝つ(LESS_EQUAL)」ため、勝者が環境依存でブレの出る＝GPUによって
境界の黒鍵が欠けて見える不具合になっていた。送信順をノート順に統一することで、
境界も内側と全く同じ順序で解決され、どのGPUでも通常鍵盤と同じ見た目になる。
（＝深度/半透明の“描画順”問題であり、透明度の有無そのものではない。）
・[FIX][独自][実験的] 無限鍵盤：note127(G9) の「右の切り欠き」を塞いでいた端キー処理を無効化。
→原因：ジオメトリ生成に「表示範囲の端キー(GetKeyDispRangeEnd==noteNo)は隣に黒鍵が無いので
切り欠きを埋めて全幅の白鍵にする」処理があり(MTPianoKeyboard White1/2/3)、無限鍵盤で端が
note127 になると note127(G) の右切り欠きが塞がれる。しかし拡張の note128(G#) はまさにその
切り欠き位置に来るため、塞いだ白鍵の天面と G# が同一面で重なり＝129鍵目だけ z-fighting。
→ 無限鍵盤時は端キーの切り欠き埋め(開始/終了とも)を行わないようにゲート。切り欠きが残るので
拡張の黒鍵が内側の黒鍵と全く同じように収まり、z-fighting が消える。
・バッファ内はノート順（各オクターブ C,C#,D,…,B）で焼き込む＝通常鍵盤の生成順と同一。
拡張部は通常鍵盤と同じ頂点色（alpha 含む）を複製するので透明度も一致。静的（押下アニメは 0-127 のみ）。
────────────────────────────────────────────────────────
Mod 20260703: infinite keyboard unified to render exactly like the normal keyboard
- [FIX][original][experimental] Infinite keyboard: the extension octaves are no longer a
separate buffer / separate Draw. They are APPENDED to the tail of each keyboard's own
vertex/index buffer, so the same single Draw covers both the normal 0-127 keys and the
extension, with the same world matrix and the same primitive submission order. The extension
therefore goes through the identical render path as the main keyboard -> no cross-draw depth
fight, so the GPU-dependent bug where white keys covered the extension's black keys is gone.
Keys are baked in note order (per octave C,C#,D,...,B) = the main keyboard's build order; the
raised black keys resolve in front just like the originals (the old white-then-black reorder
is dropped). The extension is static (only notes 0-127 animate on key press).
────────────────────────────────────────────────────────