Draft: [skip ci] Document choosing the GitLab Duo group of a Slack workspace

What does this MR do and why?

Owners and administrators need to know that every Slack workspace has one GitLab Duo group, who can choose it and how, and what people in the workspace experience until it is chosen. This MR documents that in the GitLab for Slack app page and in the development guide for testing a mention. It removes the descriptions of the default namespace and the duo-workspace project for Slack mentions, which no longer apply with the feature flag on.

The documentation follows the final behavior of the stack. It builds on !262165 (closed) and should merge together with the rest, before the feature flag leaves wip.

What's in it

• New section "Choose where GitLab Duo runs" in doc/user/project/integrations/gitlab_slack_application.md: one GitLab Duo group for each workspace, who can choose it (Owner, automatically on the first install on a top-level group, administrator for an instance-wide workspace), the requirements, the single-group rule, the several-workspaces case, the audit events.
• Updated prerequisites and intro: members of the group only, Guests are not supported, no default namespace and no Developer Flow requirement.
• doc/development/ai_features/duo_in_slack.md: how to choose the group locally, and what a mention does with and without the flag.
• Feature flag slack_duo_group added to the history.

Where this fits

This is one of a stack of merge requests. Each one targets the branch of the one before it, so review and merge them in this order. Audit events and the documentation follow as separate merge requests.

1. !261830 (closed): Table and model
2. !261845 (closed): Services to turn GitLab Duo on or off
3. !262156 (closed): Endpoint and page data
4. !262157 (closed): Mention path
5. !262158 (closed): GitLab Duo section on the integration page
6. !262159 (closed): Claim on the first group install
7. !262160 (closed): Admin area picker (self-managed)
8. !262161 (closed): Slack Marketplace install page
9. !262165 (closed): Audit events
10. !262171 (closed): Documentation (this MR)

Plan and decisions: #633566. Rollout of the feature flag: #633582. Design discussion: gitlab-org#23704.

Context for review agents

• Goal: every GitLab Duo session started from a Slack workspace runs and bills in one top-level group chosen by an Owner (the administrator on self-managed for an instance-wide install), instead of each user's default Duo namespace. Plan: #633566.
• Everything is behind the default-off slack_duo_group feature flag (type wip, becomes beta before rollout, rolled out per top-level group). The Slack flow has its own flag slack_duo_api_flow; DuoGroup.available? requires both for the same group.
• Deliberate decisions, do not flag them unless you find a real defect:
  • One Duo group per workspace (team_id unique), one group can run several workspaces. No organization_id column: namespace_id is the single sharding key. The unique index on team_id holds per cell only, tracked in #633611.
  • A group install claims the workspace, a project install does not. Copies of group or instance installs (inherit_from_id) never let a group claim a workspace. A workspace installed for the whole instance (self-managed only) is the administrator's to assign.
  • An unclaimed workspace has no fallback to the user's default namespace once the flag is on: the user gets a reply that says who can set it up.
  • A Duo group always runs the Slack API flow (slack_assistant/v1), the Developer flow is out. Members of the Duo group only, also on self-managed. Guests pass the membership check and are blocked later, documented as not supported for now.
  • Audit events for enable and disable come in a separate small MR before the flag leaves wip.
• Test world for manual validation: #633566 (comment 4012898135).
• The documentation intentionally describes the behavior with slack_duo_group on, as the feature is documented when it ships. Please check that every statement is true for the final stack, and flag anything that still describes the default namespace or the duo-workspace project.

References

• Implementation issue: #633566
• Design discussion: gitlab-org#23704

Screenshots or screen recordings

None: documentation only.

How to set up and validate locally

1. Read the changed sections: doc/user/project/integrations/gitlab_slack_application.md ("Choose where GitLab Duo runs", prerequisites) and doc/development/ai_features/duo_in_slack.md ("Choose the GitLab Duo group", "Test a mention").
2. Check that every documented step matches the product. Seed the test world (#633566 (comment 4012898135)) and follow the Owner steps on sd-a: Settings > Integrations > GitLab for Slack app > GitLab Duo in Slack. On self-managed, follow the administrator steps in the Admin area as well.
3. Check the claims about people without the Owner role: as sd-maint the group page is not reachable, and as sd-guest GitLab Duo from Slack is not supported.

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.