fix: correct upstream model binding management

[ADabbler]

Summary

Fix upstream model counting and pagination for multi-protocol bindings, make protocol-set updates atomic, and correct the model management dialog's scrolling behavior.

Observed behavior:

• A model bound to multiple protocols, such as image generation and image editing, was counted as multiple models.
• Changing the protocol set of an existing multi-protocol binding failed with a protocol-combination validation error. Users had to remove one protocol, save, and then select another protocol.
• Although the model management dialog was configured to show 25 models per page, a 15-model dataset displayed only 13 models, leaving two models inaccessible through the list view.

Before this change, the backend list endpoint paginated route rows while the UI rendered grouped model bindings, which could distort model counts and page boundaries for multi-protocol bindings. The model management dialog also used a constrained table viewport whose height and overflow behavior could prevent all rows from being accessed, including space consumed by a non-overlay horizontal scrollbar. Protocol updates were saved one route at a time, which could trigger validation against an incomplete intermediate protocol combination.

This change paginates by platform-model/upstream-model binding and replaces the complete protocol set atomically in one request. It also constrains the table viewport to the available dialog height and accounts for horizontal scrollbar space when calculating its dynamic height.

Change type

• Bug fix

Affected areas

• Frontend / UI
• Backend / API
• Model routing / providers
• Admin console

Verification

• pnpm check
• pnpm test
• pnpm build
• git diff --check

Screenshots, API examples, or logs

Configuration, migration, and compatibility notes

• The upstream model request now accepts optional routeIDs and protocols fields.
• The existing single routeID and protocol request path remains supported.
• The generated Swagger API documentation and packages/api-contract types are updated.
• No database migration is required.

Documentation

• Documentation was updated.

Security and privacy

• No secrets, tokens, credentials, local config, or personal data are included.
• User data access remains scoped by authenticated user context unless an admin-only path explicitly requires broader access.
• Security-sensitive behavior was reviewed, including authentication, authorization, provider routing, file processing, billing, and admin APIs where relevant.

Checklist

• I searched existing issues and pull requests.
• Changes are focused and do not include unrelated refactors.
• Tests or static verification were run where practical.
• User-facing behavior, deployment steps, API contracts, or configuration changes are documented.
• Generated artifacts are included only when this project explicitly requires them.
• Caches, build output, .pyc files, .env files, and local storage data are not committed.

[chenyme]

Additional fixes

• Preserve each protocol route’s existing status, priority, weight, source, circuit-breaker settings, and request headers when updating a grouped binding.
• Apply route status changes only when explicitly modified in the upstream model dialog.
• Prevent protocol, capability, or platform-model name changes from resetting unrelated route configuration.
• Use platform-model capabilities when editing bindings instead of shared upstream catalog metadata.
• Stop binding updates from overwriting shared upstream model protocol, capability, status, source, and raw metadata.
• Add concurrency-safe create-only persistence for previously unknown upstream catalog models.
• Remove the obsolete single routeID and protocol request fields.
• Regenerate Swagger and TypeScript API contracts.

Additional verification

• pnpm check
• pnpm test
• Targeted Go race tests for channel application, persistence, and HTTP packages
• pnpm api:generate
• pnpm build
• git diff --check

Additional compatibility notes

• No database migration or configuration changes are required.
• Omitted route configuration fields now preserve the corresponding existing values.
• New protocols inherit a deterministic existing route configuration; completely new bindings use server defaults.