[yoruuuchan]

Summary

• accounts.status is persisted only when pool state changes. When a cooldown simply expires, the row keeps status=cooling and its last error, so the console shows a healthy account as cooling indefinitely (observed for ~15h on a Qoder account that answered 200 immediately when pinned).
• Derive the projected status from the authoritative deadline in AccountView/Accounts: an expired account-wide cooldown with no live pool cooldown becomes ready, and the stale last_error is cleared. Active cooldowns and live pool cooldowns are untouched.
• No routing, persistence, schema, or migration changes.

Why view-level

status is a cached projection; cooldown_until and the pool's down_until are authoritative. Read-time derivation also repairs existing stale rows without a migration and cannot drift from the live pool.

Tests

• go test ./... -count=1
• go vet ./internal/runtime
• go test ./internal/runtime -count=1 (new unit tests + SQLite-backed stale-row test)
• python3 scripts/release-notes.py validate
• git diff --check

Notes

• The new test reproduces the persisted state (cooling row, expired deadline) through the real store.
• No credentials, host details, or local deployment files are included.

---

中文摘要：账号冷却到期后，数据库里的 status 不会自动重写，控制台会一直显示“冷却中”。现在在生成账号视图时按冷却截止时间判断：已过期且没有实时冷却就显示 ready，并清掉上次错误；仍在冷却中的账号不受影响。不改路由、不写库、不加迁移。