[DAP] Introduce tiered settings system with approve off by default
<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "feature" label: - https://gitlab.com/gitlab-org/editor-extensions/gitlab-language-server-for-code-suggestions/-/issues/?label_name%5B%5D=type%3A%3Afeature and verify the issue you're about to submit isn't a duplicate. ---> ### Problem to solve As an organization administrator, I want granular control over AI tool approval requirements at different organizational levels (instance, group, project), so I can enforce security policies while allowing flexibility where appropriate. Currently, tool approval settings are a simple on/off toggle that doesn't respect organizational hierarchy. This makes it difficult for enterprises to: - Set organization-wide defaults while allowing exceptions at lower levels - Lock down tool approval requirements at the top level to prevent subgroups/projects from weakening security posture - Provide a sensible default experience for new installations ### Proposal Implement a tiered settings system for AI tool approval in Duo Workflow sessions: 1. **Three-state configuration**: Replace the binary on/off toggle with a three-state system: - **Default on** – Tool approval required by default - **Default off** – Tool approval not required by default - **Never allowed** – Tool approval locked off, cannot be overridden at lower levels 2. **Hierarchical inheritance**: Settings cascade from instance → group → subgroup → project, with the most specific context taking precedence (unless locked by a higher level) 3. **Default behavior change**: New installations default to "approval not required" (`default off`) rather than requiring approval 4. **Lock mechanism**: Higher-level administrators can lock settings to prevent lower levels from weakening security policies ### Further details **Database changes**: - New setting column added to project settings - Column default changed from `true` to `false` for new installations - Migration is reversible and does not affect existing rows **API updates**: - GraphQL and REST APIs updated to support three-state approval system - Project-level configuration options added **Scope resolution**: - System checks project settings first, then group settings - Respects locks set at higher organizational levels ### Links / references - Backend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/230300 - Frontend MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/228511
issue