Pass duo-instance-enabled flag to Web IDE start config
What does this MR do?
Adds a new duo-instance-enabled data attribute to the Web IDE mount element and forwards it to the Web IDE start() config. When a GitLab instance admin sets Duo availability to "Never On", the backend now passes duo-instance-enabled: 'false' to the Web IDE initializer, providing the plumbing needed to hide the Duo status bar button entirely. The attribute is 'true' in all other states.
Why was this MR needed?
When GitLab Duo is disabled instance-wide via the Admin panel ("Never On"), the Duo button in the Web IDE status bar still appeared — but as a bright orange icon with the tooltip "GitLab Duo failed diagnostic checks." This was misleading: the feature was intentionally turned off, not broken. Organizations with IT policies prohibiting AI tools were left with a confusing, attention-grabbing button they could not remove.
Investigation confirmed that codeSuggestionsEnabled was already passed as '' when Duo is off, but the @gitlab/web-ide package uses that only to change the button's visual state, not to hide it. There was no existing config path to suppress the button entirely. A dedicated duo-instance-enabled attribute separates the instance-level admin signal from the per-user codeSuggestionsEnabled signal, and is driven by duo_never_on? — the canonical hard-lock check already used by the ai_features_banned policy condition. duo_features_enabled was considered but rejected because it is a cascading attribute: groups can override it even when the instance default is off, so using it would incorrectly hide the button for users in groups that have Duo enabled. duo_never_on? only fires when lock_duo_features_enabled is true, the only state no group can override.
Full end-to-end button hiding requires a follow-up change in the upstream @gitlab/web-ide package to read duoInstanceEnabled from ClientOnlyConfig and skip creating the status bar item when false.
What are the relevant issue numbers?
Related to #588037
Screenshots / Recordings (if applicable)
No UI change is visible from this repo alone — the button behavior is unchanged until the corresponding upstream @gitlab/web-ide package change is released and the dependency is bumped.
Does this MR meet the acceptance criteria?
- Tests added for new/changed behavior
- All tests passing
- Follows project style guide
- No breaking changes introduced