Add admin-configurable response length and per-conversation controls

Summary

Add an administrator-managed response-length policy for standard chat and optionally allow users to override the response length per conversation. Surface the user control in the chat composer beside the existing reasoning control.

User Value

Admins need a consistent default response budget that reflects their desired balance of answer detail, latency, and token cost. Users need a lightweight way to request shorter or longer answers for a specific conversation without creating an agent or repeatedly restating length instructions in prompts.

Proposed Behavior

Admin configuration

• Add an enable/disable setting that controls whether users may override response length in standard chat.
• Let admins configure the minimum, default, and maximum response-length values.
• Validate that the configured values are ordered and usable: minimum <= default <= maximum.
• Apply the configured default to standard-chat conversations that do not have a user override.

Chat experience

• When user overrides are enabled, show a response-length icon/control immediately to the right of the existing reasoning control in the chat composer.
• Clicking the control opens an accessible popover or panel containing a slider bounded by the admin-configured minimum and maximum.
• Display the active selection clearly and provide a Use admin default action/state so users can remove their override at any time.
• Save the override with the conversation so it survives navigation, reload, and later continuation of that conversation.
• Keep retries and regenerated responses consistent with the active conversation setting.
• When user overrides are disabled, hide the control and use the admin default.

Backend behavior

• Treat admin settings as authoritative. Validate every user-provided value server-side and prevent a modified client request from exceeding the configured bounds.
• Apply the resolved value through the model-appropriate output-token parameter (max_tokens or max_completion_tokens) across supported standard-chat model paths.
• Existing conversations without this field inherit the current admin default.
• If admins later narrow the allowed range, constrain previously saved overrides to the current range and reflect the effective value in the UI.
• Preserve existing agent-level max-completion-token behavior and define clear precedence when an agent with its own response cap is active.

Acceptance Criteria

• Admins can enable or disable per-conversation response-length overrides.
• Admins can configure and persist minimum, default, and maximum values, with validation enforcing minimum <= default <= maximum.
• Standard chat uses the admin default when no valid conversation override exists.
• When enabled, an accessible response-length control appears beside the reasoning control and exposes a bounded slider.
• Users can set, persist, revisit, and clear a response-length override independently for each conversation.
• Clearing the override immediately returns the conversation to the current admin default.
• Disabling user overrides hides the chat control and causes the server to enforce the admin default.
• Out-of-range or unauthorized client values cannot bypass the configured policy.
• The effective response budget reaches supported model backends through the correct token parameter, including streaming, retry, and regeneration paths.
• Existing conversations remain compatible, and saved values are handled safely after admin bounds change.
• Agent-specific token limits continue to work, with tested and documented precedence over or interaction with the standard-chat setting.
• Functional and UI tests cover settings validation, fallback behavior, conversation persistence, reset-to-default, server enforcement, and composer interaction.

Notes

• This control sets an output-token ceiling; it allows a longer response but does not guarantee that the model will use the full budget. UI copy should not imply a guaranteed answer length.
• Agents already expose max_completion_tokens; this request brings equivalent control to the normal chat experience while retaining centralized admin policy.
• The existing reasoning control in application/single_app/templates/chats.html is the intended neighboring UI pattern.
• Related to, but distinct from, #933, which tracks cumulative user/conversation token quotas and usage indicators rather than a per-response output cap.