fix(client): enforce colorless color identity for colorless commanders

[jeffrey701]

Problem

isInColorIdentity (client/src/components/deck-builder/commanderUtils.ts) began with if (identity.length === 0) return true;. For a genuinely colorless commander (e.g. Kozilek, Butcher of Truth — color identity []), the combined identity is empty, so every card was treated as legal. A red card like Lightning Bolt passed the color-identity check, but CR 903.5c permits only colorless cards in a colorless commander's deck.

The subtlety (and why a naive fix is wrong): that same empty-identity short-circuit also absorbed the "commander card data hasn't loaded yet" case — a cache miss yields an empty identity too. Dropping the short-circuit outright would flag every colored card in the deck during the async card-data load window (false positives on a fresh open).

Fix

• Remove the identity.length === 0 -> true short-circuit from isInColorIdentity; card.color_identity.every(c => set.has(c)) already does the right thing — [].every() is true (colorless card legal), a colored card is false (violation).
• Move the loading guard to getColorIdentityViolations: return [] until every commander's data is cached, so a cache miss can't masquerade as "colorless commander."

Behavior for colored commanders and for the loading window is unchanged; only the genuinely-colorless-commander case is corrected.

Tests

Adds commanderUtils.test.ts: a colorless commander (Kozilek) now flags an off-color card and allows a colorless one (fails before the fix — no violation reported); a colored commander still flags only off-color cards; and an unloaded commander yields no violations (no false positives mid-load).

Self-contained: only commanderUtils.ts + a new test; no engine/Rust/protocol changes.

Model: claude-opus-4-8

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!