[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