feat: support MiniMax embedding backend (non-OpenAI-compatible /v1/embeddings)

Feature description

Add first-class support for MiniMax as a PowerContext embedding backend.

Today PowerContext's embedding adapter only speaks the OpenAI embeddings contract. MiniMax exposes /v1/embeddings under an OpenAI-looking path but uses a different request/response shape, so it cannot be used as an "OpenAI-compatible" embedding endpoint. Users who already run generation on openai-chat:MiniMax-M3 cannot complete their inference configuration because no compatible embedding provider is available.

Problem and proposed solution

The incompatibility (reproduced)

PowerContext builds the embedding request through Pydantic AI's OpenAI client, which sends the standard OpenAI body:

POST /v1/embeddings
{ "model": "embo-01", "input": ["hello"], "dimensions": 1536 }

MiniMax rejects this and returns HTTP 200 (not 4xx) with a vendor error envelope:

{ "vectors": null, "base_resp": { "status_code": 2013, "status_msg": "invalid params, binding: expr_path=texts, cause=missing required parameter" } }

Two divergences from the OpenAI embeddings API:

1. Request shape: MiniMax requires texts + type (e.g. {"texts":["hello"],"type":"db"}), not input.
2. Response shape: MiniMax returns {vectors: [...], base_resp: {...}} instead of OpenAI's {data: [{embedding: [...]}]}. On error it returns vectors: null together with a base_resp.status_code.

Because the response never contains a data array, Pydantic AI raises during parsing and PowerContext surfaces a generic InferenceError (InferenceUnavailableError / InvalidInferenceOutputError). The failure is loud — no malformed vectors are stored in the index — but the message ("provider rejected" / "did not return a valid result") does not tell the operator that the endpoint is simply not OpenAI-compatible, which makes the root cause hard to diagnose.

Generation works correctly: openai-chat:MiniMax-M3 against https://api.minimaxi.com/v1 returns valid results, so the gap is specific to embeddings.

Proposed solution

Add a MiniMax embedding adapter (or a small, provider-keyed request/response transform) so that when the embedding provider is MiniMax:

• the request body uses texts + type instead of input;
• the response is parsed from vectors, and a non-zero base_resp.status_code is mapped to a clear, named error.

Minimal alternative: at minimum, detect a non-OpenAI embeddings response (missing data, or a vendor error envelope such as base_resp) and raise a diagnostic InferenceError that explicitly states the endpoint is not OpenAI-compatible, so operators stop guessing.

Alternatives considered

• Use a different OpenAI-compatible embedding provider (OpenAI text-embedding-3-small, DashScope text-embedding-v4, or any OpenAI gateway). This works today and is the current workaround, but it forces users who standardize on MiniMax to run a second vendor just for embeddings.
• Generic custom-transform hook for embeddings (user-supplied request/response mapping). More flexible but a larger surface; a MiniMax-specific adapter is a lower-risk first step.

Additional context

• PowerContext version observed: powercontext-v1.0.0-46-gee5c076e (CLI self-report 1.0.1.dev20+ged11e5b65).
• Evidence captured via curl against https://api.minimaxi.com/v1/embeddings (key omitted). Native MiniMax call {"texts":["hello"],"type":"db"} returns 1536-dim vectors, confirming the key has embedding permission and only the API shape differs.
• Generation config that works:
  • POWERCONTEXT_SERVER_INFERENCE_GENERATION_MODEL=openai-chat:MiniMax-M3
  • POWERCONTEXT_SERVER_INFERENCE_GENERATION_BASE_URL=https://api.minimaxi.com/v1
• This is distinct from integrations/minimax/, which is about MiniMax Code connecting to PowerContext as an MCP client. This issue is about PowerContext consuming MiniMax as an inference backend.

I am willing to contribute the code change.

Start by tracing PowerContext's embedding adapter and its Pydantic AI OpenAI client integration; the issue does not name specific files or tests. Compare the existing OpenAI request and response flow with MiniMax's /v1/embeddings contract. Done means MiniMax sends texts and type, parses vectors, and reports non-zero base_resp.status_code values with a clear named error.