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.