feat: supports hiding internal task models from external display

[chenyme]

Summary

Add model availability scope so admins can mark platform models as either platform-wide or internal-task-only. Internal task models are hidden from user model lists and blocked from direct user routing, while system tasks such as title generation, labels, and compaction can still route to them explicitly.

The implementation adds a first-class access_scope platform model field, routes user and internal calls with explicit scope, uses a safe default that treats missing/unknown route scope as user scope, and adds admin UI controls for configuring the scope from the model sheet and models table.

Change type

• Bug fix
• Feature
• Documentation
• Refactor
• Configuration / deployment
• Security hardening
• Other

Affected areas

• Frontend / UI
• Backend / API
• Authentication / authorization
• Conversations / streaming
• Files / RAG / extraction
• Model routing / providers
• MCP / tools
• Billing / payments
• Admin console
• Deployment / Docker / configuration
• Documentation

Verification

• cd backend && go test ./internal/application/channel/... ./internal/application/conversation/... ./internal/transport/http/channel/... ./internal/infra/persistence/postgres/channel/...
• cd frontend && pnpm lint
• i18n JSON parse check for zh-CN and en-US admin model messages

Screenshots, API examples, or logs

Not included. UI change is limited to the admin model form/table availability controls.

Configuration, migration, and compatibility notes

Adds llm_platform_models.access_scope varchar(32) NOT NULL DEFAULT 'public' through the PostgreSQL baseline. Existing models remain platform-wide by default.

Admin model create/update APIs now accept and return accessScope with values public or internal. Public model listing excludes internal-task models.

Documentation

• Documentation is not needed for this change.
• Documentation was updated.
• Documentation still needs to be 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.