Problem
Original text:
「我還想要有一個排序按鈕是可以選擇照著帳號順序排序，還是著weekly重置的緊迫時間排序」
— Source: user, live session 2026-08-03
帳號用量視窗目前固定照 registry 順序列出帳號（List(model.accounts)，RegistryUsageModel.load() 直接 map registry.accounts，沒有任何排序層）。使用者要一個排序切換按鈕，至少兩種模式：
- 帳號順序 —— 現行行為（registry 順序），維持穩定、位置可預期。
- weekly 重置緊迫度 —— 依 weekly 用量視窗的重置時間排序，最緊迫的排前面。
Type
feature
Expected
帳號用量 toolbar 有一個排序控制（按鈕或 Picker），可在「帳號順序」與「weekly 重置緊迫度」之間切換；選擇會被記住（下次開窗沿用）。
Actual
沒有排序控制，順序固定為 registry 順序。
Impact
帳號數量多的時候（本機 registry 已達數十個），「哪個帳號的 weekly 快重置了 / 哪個最該現在用」必須靠人眼掃過每一列的「重置於 …」。排序按鈕把這個判斷從掃描變成看第一列。
Open questions（留給 diagnose / plan）
- 「緊迫」的定義：純粹依
resetsAt 由近到遠？還是應該把 percentRemaining 併進來（快重置但還剩 90% 並不緊迫；剩 5% 且還要等三天才緊迫）？兩種排序給出的順序可能完全相反，這是主要待決點。
- 沒有 weekly 視窗的帳號怎麼擺：
.loaded 但 windows 為空、.noCredentials、.needsLogin、.failed、還在 .loading 的帳號，在緊迫度模式下沒有 key 可比 —— 一律沉底？沿用 registry 相對順序？
- 持久化位置：
UserDefaults（跟其他 UI 偏好一致）還是不持久化。注意 XCUITest 走的是 volatile suite，別讓它污染真實偏好。
- 控制項形狀：toolbar
Picker / Menu（可擴充第三種排序，例如「剩餘百分比」）vs 單純 toggle 按鈕。
Problem
帳號用量視窗目前固定照 registry 順序列出帳號（
List(model.accounts)，RegistryUsageModel.load()直接 mapregistry.accounts，沒有任何排序層）。使用者要一個排序切換按鈕，至少兩種模式：Type
feature
Expected
帳號用量 toolbar 有一個排序控制（按鈕或 Picker），可在「帳號順序」與「weekly 重置緊迫度」之間切換；選擇會被記住（下次開窗沿用）。
Actual
沒有排序控制，順序固定為 registry 順序。
Impact
帳號數量多的時候（本機 registry 已達數十個），「哪個帳號的 weekly 快重置了 / 哪個最該現在用」必須靠人眼掃過每一列的「重置於 …」。排序按鈕把這個判斷從掃描變成看第一列。
Open questions（留給 diagnose / plan）
resetsAt由近到遠？還是應該把percentRemaining併進來（快重置但還剩 90% 並不緊迫；剩 5% 且還要等三天才緊迫）？兩種排序給出的順序可能完全相反，這是主要待決點。.loaded但windows為空、.noCredentials、.needsLogin、.failed、還在.loading的帳號，在緊迫度模式下沒有 key 可比 —— 一律沉底？沿用 registry 相對順序？UserDefaults（跟其他 UI 偏好一致）還是不持久化。注意 XCUITest 走的是 volatile suite，別讓它污染真實偏好。Picker/Menu（可擴充第三種排序，例如「剩餘百分比」）vs 單純 toggle 按鈕。