fix(embedder): bound OpenAI HTTP connection pools

[ranxi2001]

Description

Current main already reuses one async OpenAI client per event loop. Those clients, and the synchronous client, still let the OpenAI SDK create its default HTTP transport. In the locked SDK that means up to 1000 connections and 100 idle keepalive connections, well above OpenViking's default embedding concurrency of 10. The embedder also had no close() implementation for its sync client or cached async clients.

This change gives every OpenAI and Azure embedding client an SDK-default HTTP transport whose connection and keepalive limits follow the existing max_concurrent setting. Validated configuration now rejects values below one, while direct embedder construction preserves the existing one-request fallback instead of creating a pool that can only time out. The SDK timeout behavior and five-second keepalive expiry remain unchanged.

The service now closes and clears its embedder after queue workers and vector storage stop, so the sync client and all event-loop-scoped async clients are released during normal shutdown.

Human Involvement

• A human participated in the implementation or review loop
• This PR was generated entirely by AI agents without human participation in the loop

Related Issue

Fixes #4462

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test update

Changes Made

• bound sync and async OpenAI/Azure HTTP pools to the configured embedding concurrency;
• reject embedding.max_concurrent < 1 and normalize direct-constructor values to one;
• preserve the OpenAI SDK's existing timeout and keepalive-expiry defaults;
• close and clear the service-owned embedder during normal shutdown; and
• document the positive concurrency requirement and add transport, boundary, reuse, and cleanup regression coverage.

Testing

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have tested this on the following platforms:
  • Linux
  • macOS
  • Windows

Local checks:

• 42 focused OpenAI/Azure embedder, request-configuration, pool-boundary, and lifecycle tests passed;
• 4 embedding-configuration and existing service-close tests passed;
• a controlled local HTTP/1.1 endpoint confirmed that two sequential async embeddings reuse one TCP connection and that cleanup closes both SDK clients;
• zero and negative validated concurrency values are rejected, while direct construction produces a one-connection pool instead of PoolTimeout; and
• Ruff lint and format checks, Python compile checks, and git diff --check passed on the changed files.

Checklist

• My code follows the project's coding style
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published

Screenshots (if applicable)

Not applicable; this backend connection-management change has no visual output.

Additional Notes

The issue's keepalive_expiry=inf description does not match the currently locked OpenAI SDK, which uses five seconds. The oversized 1000/100 connection limits are still present and are the behavior this PR bounds. Validation used a controlled local server, not a sustained production llama.cpp workload. Pool sizes and timeouts are not added as new configuration fields, and other embedding providers are unchanged.