feat(common): register FriendliAI model IDs and provider prefix

[rekty]

{
"title": "feat(common): register FriendliAI model IDs and provider prefix",
"head": "rekty:feat/friendli-model-ids",
"base": "main",
"body": "Closes #1089\n\nFriendliAI serves several models already present in the catalog under other providers. Registering their exact HuggingFace-cased IDs under a friendli/ prefix means a maintainer can route them through the private backend (web/src/llm-api/) with no further public changes.\n\n### What this does\n\n- Adds friendli to ALLOWED_MODEL_PREFIXES so the new IDs pass isExplicitlyDefinedModel() and agent-template validation.\n- Introduces a friendliModels map with two serverless models (GLM-5.2, MiniMax-M2.5) and spreads it into the canonical models object.\n- Adds friendli.ai to providerDomains and a friendli/ prefix check in getLogoForModel so the favicon resolver picks up the right domain.\n\n### What a maintainer port would need to do next\n\nAll inference routing lives behind the private web/src/llm-api/ boundary. The pieces a matching routing file would need:\n\n| Detail | Value |\n|---|---|\n| Endpoint | https://api.friendli.ai/serverless/v1/chat/completions |\n| Auth | Bearer <token> + optional X-Friendli-Team |\n| Metadata | GET .../serverless/v1/models |\n| Reasoning | boolean parse_reasoning / include_reasoning, chat_template_kwargs.enable_thinking; response field reasoning_content (not thinking block) |\n| Incompatibility | response_format + tools together returns 422 |\n| IDs | Case-sensitive exact HuggingFace casing |\n\nTests:\n- bun test common/src/__tests__/model-config.test.ts — 7 pass\n- bun test common/src/__tests__/freebuff-peak-hours.test.ts — 24 pass"
}

[codebuff-team]

The mechanics here follow the existing pattern (minimax, mimo, tencent prefixes) reasonably well — prefix allowlist, a models map, providerDomains, and the getLogoForModel branch are all touched consistently, and the diff is small and easy to read.

The problem is the payload. GLM-5.2 and MiniMax-M2.5 are not model versions that exist publicly as of this writing — the real lineages are GLM-4.x from Zhipu/Z.ai and MiniMax-M1/M2 from MiniMax. Registering IDs that don't correspond to anything FriendliAI actually serves means this addition is either speculative or incorrect, and either way it's not something a maintainer can port as-is — they'd have to first verify the IDs against FriendliAI's /serverless/v1/models endpoint themselves, which defeats the purpose of the PR doing that legwork.

Separately: without the private web/src/llm-api/ routing wired up, these entries do nothing except pass validation and resolve a favicon — that's fine as a preparatory PR in principle, but only if the underlying model IDs are real. The PR body's routing table (auth headers, reasoning field names, the response_format+tools 422 conflict) is oddly specific for models that don't appear to exist, which raises the question of whether this was generated rather than verified against FriendliAI's actual docs.

Before this is portable: confirm the exact model IDs FriendliAI currently serves (via their models endpoint or docs) and swap in real, currently-available IDs. Also worth spreading friendliModels in a diffable location relative to the map ordering used by other providers if there's a documented convention (unclear from this diff alone).