feat: provider/account-level concurrency cap enforcement

[kang-heewon]

Summary

• DB schema & migration: Added provider_connections.max_concurrent column (migration 028) for declarative per-account concurrency limits.
• Account semaphore: New open-sse/services/accountSemaphore.ts — in-memory FIFO queue keyed by provider:model:account with acquire()/release()/timeout/block hooks.
• Request pipeline integration: chatCore.ts acquires account semaphore slot before dispatching upstream. Requests beyond the cap wait in queue or timeout with SEMAPHORE_TIMEOUT; fallback routes remain active.
• Provider DB module: round-trip maxConcurrent through createConnection/getProviderConnectionById/updateProviderConnection. Added cleanNulls() fix to preserve explicit null values.
• REST API: Provider limits route (/api/v1/providers/[provider]/limits) expanded to GET/PUT maxConcurrent.
• Dashboard UI: Provider detail page now exposes account-native cap input with descriptive hint. ResilienceTab combo concurrency label clarified to distinguish combo-level from account-level.
• i18n: EN/KO translations for new labels and hints.
• Schema validation: maxConcurrent validates non-negative integers, accepts null/undefined as unlimited.
• Tests: 6 semaphore unit tests + 6 DB round-trip/validation tests, all passing.

Motivation

Some providers (e.g. Alibaba) enforce per-account native concurrency caps (e.g. max 3 concurrent requests → 429 on excess). Previously there was no declarative way to enforce these caps before upstream rejection. This adds an account-level semaphore layer that sits alongside the existing model-level semaphore, providing two-tier concurrency control.

Changed Files

File	Type	Description
src/lib/db/migrations/028_provider_connection_max_concurrent.sql	New	DB migration
open-sse/services/accountSemaphore.ts	New	Account-level semaphore
open-sse/services/__tests__/accountSemaphore.test.ts	New	Semaphore tests (6)
tests/unit/account-concurrency-cap.test.ts	New	DB round-trip + validation tests (6)
open-sse/handlers/chatCore.ts	Modified	Semaphore acquire/enforcement
src/lib/db/providers.ts	Modified	maxConcurrent round-trip + cleanNulls
src/app/api/providers/[id]/route.ts	Modified	maxConcurrent in limits API
src/shared/validation/schemas.ts	Modified	maxConcurrent Zod validation
src/app/(dashboard)/dashboard/providers/[id]/page.tsx	Modified	Account cap UI input + hint
src/app/(dashboard)/dashboard/settings/components/ResilienceTab.tsx	Modified	Combo concurrency label clarification
src/app/(dashboard)/dashboard/combos/page.tsx	Modified	Reference to combo concurrency
src/i18n/messages/en.json	Modified	EN translations
src/i18n/messages/ko.json	Modified	KO translations

QA

• ✅ npm run lint — 0 errors
• ✅ npm run typecheck:core — PASS
• ✅ npm run build — PASS
• ✅ accountSemaphore.test.ts — 6/6 PASS
• ✅ account-concurrency-cap.test.ts — 6/6 PASS

Breaking Changes

None. maxConcurrent defaults to null (unlimited) — existing accounts unaffected.

[gemini-code-assist]

Code Review

This pull request introduces an account-level concurrency semaphore to manage and limit simultaneous requests per provider account, addressing issues where providers enforce strict native caps. It includes a new accountSemaphore service, database migrations to store max_concurrent settings, and UI updates to configure these limits. However, the current implementation has a critical flaw where the semaphore is released prematurely for streaming requests, potentially bypassing the concurrency limit. Additionally, the semaphore key includes the model name, which contradicts the goal of enforcing a total account-level limit across all models. Finally, the new test file violates the project's style guide regarding file placement.