feat(api): abort signal pass-through for simple providers #616

Parent issue

Part of #404 — Stop does not abort underlying HTTP request
Depends on #615 (core plumbing)

Scope

~18 providers where the fix is a one-liner: pass signal: metadata?.abortSignal to an existing SDK call. All follow the same pattern and are low-risk.

Providers

openai-compatible.ts, openai.ts, anthropic.ts, anthropic-vertex.ts, deepseek.ts, lm-studio.ts, lite-llm.ts, mimo.ts, minimax.ts, poe.ts, qwen-code.ts, requesty.ts, opencode-go.ts, unbound.ts, vercel-ai-gateway.ts, xai.ts, zai.ts, zoo-gateway.ts, openrouter.ts

Pattern

For createMessage (streaming):

const response = await streamText({
  ...params,
  abortSignal: metadata?.abortSignal,
})

For completePrompt (non-streaming):

const response = await generateText({
  ...params,
  abortSignal: metadata?.abortSignal,
})
// or for OpenAI SDK:
const response = await this.client.chat.completions.create(params, {
  signal: metadata?.abortSignal,
})

Style note from review

Use the simple direct object pattern ({ signal: metadata?.abortSignal }) rather than the variadic spread-of-array trick. Passing undefined for signal is harmless.

Tests

Each provider should add a describe("abort signal") block to its existing spec file (not a separate file). Verify signal is forwarded via expect.objectContaining with reference identity (toBe).

Acceptance criteria

• All listed providers forward abortSignal in both createMessage and completePrompt
• Each has at least one test verifying signal propagation