Interest check: multi-provider support (Kimi / GLM / Grok) + user-assignable island slots

[Jason880902]

Hi! I maintain a downstream fork (Jason880902/codex-island) that grew a feature you might want upstream: the island's two slots are no longer hardwired — users pick any two of Kimi, Codex, Claude, Grok, GLM, and the peek pills, expanded panel, Overview, and threshold alerts all follow the assignment.

Before I start porting it over as PRs: is this a direction you'd accept? It's a big surface (~3k lines in my fork), so I'd split it into small, reviewable pieces — roughly:

1. Provider vocabulary unification — one shared AlertEngine.Provider enum (kimi, codex, claude, grok, glm); UsageStore / CostStore become provider-keyed dictionaries. Pure refactor, no behavior change.
2. Slot store — ProviderVisibilityStore becomes a Left / Off / Right slot store with swap-on-conflict assignment and legacy-key migration (Kimi-left / Codex-right).
3. Kimi provider — fetcher + file-based credential handling. Includes one fix you may want regardless: Kimi access tokens live ~15 minutes and rotate mid-session, so local expiry no longer clobbers the last good reading — only a server-side 401 does.
4. GLM + Grok providers — Settings-entered keys (no local CLI store to read), defensive parsers, honest "not configured" states until keys exist.
5. Zero-rate subscription pricing — flat-plan providers (Kimi/GLM/Grok) get known-model zero-rate entries so the Cost page tracks token volume, not dollars.

Honest caveats:

• The GLM/Grok endpoints were not testable against live accounts at implementation time (no key, no cookie) — the parsers are deliberately tolerant and fixtures pin the expected payload shapes, but someone with a real account should validate before merge.
• More providers means more account-level rate-limit edge cases; my fork handles them with per-provider post-429 cooldowns and retention-through-transient-errors, but it's surface area you'd inherit as maintainer.

The fork's code is MIT (yours), README/CHANGELOG there have the full story. Happy to adjust the split, start with whichever piece is most palatable (the Kimi rotation fix and the provider-enum refactor are the most self-contained), or drop the idea entirely if it doesn't fit your roadmap.