Use aieo's xAI provider instead of hand-rolled workarounds

[Evanfeenstra]

Summary

Follow-up to #5227. That PR added xAI as a provider but worked around the installed aieo (0.1.34) lacking an xai entry, with a hard throw in the canvas agent, a client-side picker filter, and comments pointing at "feature notes" that don't exist. The xai support had actually landed in aieo (stakwork/stakgraph#1565) but was never published; aieo 0.1.35 is now out with it.

• Bump aieo to ^0.1.35
• Remove the runCanvasAgent throw for xai/* models. Grok now flows through the same generic aieo provider branch as every other provider, with aieo doing the key lookup
• Remove the client-side XAI filter in CanvasAgentSettingsPopover; /api/llm-models already filters by configured key server-side
• Delete runCanvasAgent-xai.test.ts, which pinned the throw
• Add models-aieo-parity.test.ts. models.ts is imported by client components so it can't import aieo directly; this test pins its provider→env-var table to aieo's PROVIDERS and hasApiKeyForProvider so the two can't drift again
• Rewrite the stale comments in models.ts, the agent route, task-workflow.ts, and env.ts

Deliberately kept

• Bifrost bypasses in /api/agent and callStakworkAPI. The blocker is no longer aieo: DEFAULT_PROVIDERS in src/services/bifrost/constants.ts has no xai entry and the swarm gateways have no xai provider key. Comments now say exactly that. Remove once the gateways carry an xai key.
• Legal benchmark XAI exclusion. Exists because the judge is Anthropic-only and the pair shares one key; unrelated to aieo.

Test plan

• tsc --noEmit clean on non-test files (after prisma generate)
• eslint clean on changed files
• Unit suites for lib/ai, user preferences, task-workflow, call-stakwork-api pass (980 tests incl. 10 new parity checks). The one failure in graphWriteAuth.test.ts is pre-existing and reproduces on a clean tree.

🤖 Generated with Claude Code