Publish OSS release snapshot 2.4.4 - #306

水位修正（tools/upstream_baseline.json）：

reviewed_pr_through 483 → 462、reviewed_issue_through 482 → 0。原本那組數字等於
宣稱「上游 PR 與 issue 都審過了」，但沒有人看過那 8 個仍開啟的 PR，一個上游 issue
也還沒對本 fork 分診過。462 是誠實的：本 fork 的 HEAD 就是 PR NVIDIA#462 的合併點，
合併到 NVIDIA#462 為止的每個 PR 都字面存在於這棵樹裡，不需要移植；NVIDIA#462 以上的都是未合併、
未審。issue 那一軸據實寫 0。

判定記錄（docs/UPSTREAM.md，新增）：

fork 繼承的 36 個分支全部給出書面判定——「刪掉」不等於「處理過」，判定要寫下來
才算。分四組：

- A（22 個）：commits 已 patch-id 相同地在 main 裡，內容已在樹上。
- B（4 個）：上游 PR 已定案。NVIDIA#332／NVIDIA#306 已合併＝已在樹上；NVIDIA#155／NVIDIA#235 關閉未合併，
  由同期的 -2 後續分支取代（此為依命名慣例與關閉時間的推論，檔內已標明不是上游明說）。
- C（8 個）：上游 PR 仍開啟，逐筆四點評估（缺陷是什麼／本樹是否有這段程式／判定／
  回頭再看的觸發點）。本樹與上游逐字元相同，所以這些缺陷在這裡全部存在——問題是
  「現在移植」還是「等上游合併」，不是「適不適用」。八筆全部判「等上游合併」，
  但各有各的理由與觸發點：NVIDIA#470 的 letter-spaced P3/P4 是純靜態路徑就能繞過的真實
  安全缺口，優先序最高；NVIDIA#383/NVIDIA#430/NVIDIA#442 是同一個 dependency-source redirection 能力的
  三個疊加嘗試，提前選邊會造成合併衝突白工。
- D（2 個）：從未成為 PR，任何水位都追不到。已從上游 fetch 回來評估後判「不適用」
  （NIM provider 是功能擴充非缺陷修正、且無使用情境；revert-306 是上游自己開了又
  放棄的提案），判定寫入後才刪除。

驗證：pwsh -NoProfile -File tools/dev_check.ps1 → WINDOWS DEV CHECK GREEN、exit 0
（3953 passed、39 skipped、4 xfailed）。python 驗過 baseline JSON 可解析。

Co-Authored-By: Claude Opus 5 <[email protected]>