Create table to track consents for features at namespace level

What does this MR do and why?

Introduces the namespaces_consents table and Namespaces::Consent model as generic, reusable infrastructure for recording explicit namespace-level consent to activate a named feature.

This is foundational work for the DAP-based code review routing change (&22247): groups that already have Code Review Flow enabled must explicitly re-confirm before new routing takes effect. A dedicated consent table — modelled after user_group_callouts — records which namespace consented, which feature was consented to, who triggered the consent, and when, making it auditable and extensible to future consent-gated features without schema changes.

Changes

• Migration (db/migrate/20260611000001_create_namespaces_consents.rb): creates namespaces_consents with namespace_id (FK → namespaces ON DELETE CASCADE), nullable user_id, feature_name (smallint enum), and timestamps. Unique index on (namespace_id, feature_name).
• Loose foreign key (config/gitlab_loose_foreign_keys.yml): user_id → users (async_nullify) — consent belongs to the namespace, not the user, so user deletion nullifies rather than deletes the row.
• Database dictionary (db/docs/namespaces_consents.yml): gitlab_main_org, sharding key namespace_id: namespaces.
• Model (app/models/namespaces/consent.rb): Namespaces::Consent with feature_name enum (code_review_flow_dap_routing: 1), presence + uniqueness validations.

Database analysis for the new table

What is the anticipated growth for the new table over the next 3 months, 6 months, 1 year? What assumptions are these based on?

There will be a max of 1 record per toplevel group (TLG) - 1:1 with namespaces with a Duo Enterprise license that were given consent to use DAP DCR, so it's a very controlled and low rate growth table.

How many reads and writes per hour would you expect this table to have in 3 months, 6 months, 1 year? Under what circumstances are rows updated? What assumptions are these based on?

Based on the anticipated data volume and access patterns, does the new table pose an availability risk to GitLab.com or GitLab Self-Managed instances? Does the proposed design scale to support the needs of GitLab.com and GitLab Self-Managed customers?

No.

As many reads as code review flows executed. Again, very low rate. Rows are never updated, it's an append-only table.

References

• Closes #602688 (closed)
• Parent epic: gitlab-org#22247

Screenshots or screen recordings

No UI changes — infrastructure only.

How to set up and validate locally

1. Run the migration:

   bundle exec rails db:migrate

2. In a Rails console, verify the table and model:

   group = Group.first
   Namespaces::Consent.create!(namespace: group, user: User.first, feature_name: :code_review_flow_dap_routing)
   group.namespace_consents

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.