feat(providers): add Unifically as an OpenAI-compatible gateway

[unifically-dev]

Adds Unifically as an OpenAI-compatible API-key gateway, in the same shape as #13025 (eurouter): default executor, no translator, passthroughModels, models: []. I work on Unifically. This replaces #14124, which I opened from the wrong account.

modelsUrl is /v1/models?category=llm. The catalog is one list for text, image, video and audio, and 30 of its 155 models are llm. Only those take chat completions. The media models run through an async task API that the default executor does not speak, so an unscoped listing would offer 125 models that fail on every request. There is a test pinning the scoped URL.

Checked against the live API on 2026-09-18:

GET  /v1/models                 -> 200, OpenAI-shaped list, 155 models
GET  /v1/models?category=llm    -> 200, 30 models
GET  /v1/models  (no key)       -> 401
POST /v1/chat/completions       -> 200, chat.completion
POST /v1/chat/completions stream:true -> SSE chunks, final usage chunk, data: [DONE]

Auth is Authorization: Bearer <key>. No tool or vision capability is declared because I did not exercise either. hasFree is false: new accounts get a one-time starting balance, which is not a free tier. It is in AGGREGATOR_PROVIDER_IDS since it routes to third-party model providers.

One bug on our side: in the streamed response the final usage chunk reports completion_tokens: 0. It does not affect routing.

tests/unit/unifically-provider.test.ts passes (7) and eurouter-provider.test.ts still passes. gateways.ts grows by 19 lines of catalog data, so file-size-baseline.json will need the usual note on merge.

[diegosouzapw]

Re-homed to release/v3.8.52: v3.8.51 entered its release freeze, so the branch now belongs to the release captain and development continues on the next cycle. Nothing is wrong with this PR — it just needed a live base. No action needed from you; CI will re-run against the new base.