Add the Agent Platform row to the Duo readiness card

What does this MR do and why?

Adds the Agent Platform row, first in the Required card: whether the Agent Platform is switched on above this project, and who can change that if it is not.

Read-only. Where the switch lives depends on the deployment, so the copy and the link differ — the group and its Owners on SaaS, the instance and its administrators otherwise. When the viewer cannot reach those settings, no action is rendered rather than a link they cannot follow.

Nothing else in the card can be set up while this is off, which is why it sits first.

Related to #607581. Stacked on !247931 (merged).

Also lands the shared scaffolding

This is the first row, so it brings the pieces the later rows build on:

• Ai::DuoWorkflow::ProjectReadiness — the read model behind the rows
• the duoReadiness key in gitlab_duo_settings_data

Both are skipped entirely when the card will not render. That matters because this runs on project general settings, loaded by every maintainer, rather than a dedicated page — and platform availability re-queries the Ai::Setting singleton on every call on self-managed, so it is memoized.

Also groups the remaining settings

The card answers "can agents run here". Everything below it is project-wide behaviour that has nothing to do with readiness, so the design separates the two with a rule and an Other Duo settings heading.

The heading only appears alongside the card, so the flag-off page keeps its current ungrouped layout.

Review round 3

The gate no longer includes duo_agent_platform_available? — the feature flag alone decides whether the card renders, and the platform switch became reportable state (platformEnabled), per the design's blocked cascade. Raised by @alejandro: the old gate made platformEnabled a constant, so the Agent Platform row could never show its error state.

FF	platform	renders
off	any	flat list, as on master
on	on	card — platform row done
on	off	card — platform row error, every row below blocked and disabled

The only behavioral change is the last cell (it previously fell back to the flat list). Blocking the GitLab Duo toggle under a dead platform freezes a setting that also governs Chat — deliberate, faithful to the prototype, and tracked for a design ruling in #608268.

The new cell, captured on GDK (SaaS mode, group platform switched off — the row names the Group Owner and links their settings; every row below is blocked with its toggle disabled; the flow rows additionally show the pre-existing cascading ancestor lock, since the group locks flows when its platform is off):

Feature flag

Behind duo_agent_readiness_settings (wip, user actor, default off) — #607567. With the flag off the page renders exactly as it does today.

Test plan

• Row states: on/off × SaaS/self-managed, plus the no-permission case where no action renders
• Helper spec asserts the readiness reads are skipped when the card is off
• A spec asserts platform availability is read once per instance, not per call
• A spec pins that the flag-off page renders neither the card nor the heading
• 466 frontend examples pass across the permissions components

Flag-off was also checked by rendering the component against a master worktree and diffing the output: identical.

Screenshots or screen recordings

Flag off (renders as master does today)	Flag on