feat: implement media image streaming capabilities

[chenyme]

Summary

This PR adds admin-controlled image streaming capability configuration and improves the user-side model configuration experience.

Image generation now keeps the existing default streaming behavior, while allowing admins to explicitly disable image streaming per model through ModelCapabilitiesJSON.image.stream=false. User-supplied options still cannot control stream; the backend decides the execution strategy from model capabilities and adapter support.

The chat model configuration dialog was also refined: missing option translation keys no longer produce console errors, the visual/JSON configuration panes now use fixed-height scroll regions, and project navigation interactions were split so the icon toggles project expansion, the text area starts a new project chat, and the menu button keeps its current behavior.

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/conversation/...
• cd frontend && pnpm lint

Screenshots, API examples, or logs

Not included.

Configuration, migration, and compatibility notes

No database migration or deployment configuration changes are required.

image.stream=false is a new optional model capability flag. Omitted or invalid capability JSON keeps the existing default behavior. User-level stream options remain blocked by the option policy.

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.