Add new and edit actions to group Policy Store

What does this MR do and why?

Rounds out the group-level Groups::Security::PolicyStoreController with new and edit actions alongside the existing index, and wires the list to navigate to those pages — mirroring the organization-level controller in !249442 (merged).

Organizations are the target architecture for Policy Platform ownership/scoping, but adoption is still maturing. Keeping a complete group-level entry point ensures the experiment has a viable fallback while Organizations support lands.

Commits:

1. Controller / routes / views — adds new/edit and moves authorization from read_security_orchestration_policies to the govern_policy abilities, matching the organization MR: read_govern_policy gates index, update_govern_policy gates new/edit. The experiment gating is unchanged (group.policy_store_experiment_active?, 404 when inactive). GroupPolicy now grants the full govern_policy set (create/read/update/delete) to admins and group owners; auditors additionally get read_govern_policy because they can already read v1 security policies. resources :policy_store expanded to [:index, :new, :edit] with an id constraint; JS route helpers regenerated. The #js-policy-store mount is extracted into an _app partial rendered by index/new/edit, with page bundles for new/edit.
2. List navigation (shared FE) — the list renders the new/edit pages as dedicated views selected by an injected initial view. The Create new policy button is a link to a backend-supplied new policy path, and each policy links to its own edit path. The client never builds paths; edit paths are mocked on the policy for now, mirroring the v1 policies list, until the list endpoint exists.
3. Group paths — the group views supply the new policy, edit, and list paths so the list navigates to the dedicated group pages.

Notes / scope

• Commit 2 is a generic frontend change shared with the organization MR. It is committed identically in both branches, so each MR is self-contained and the two 3-way-merge cleanly — they are fully independent and neither needs the other to merge.
• Behind the experiment gating (flag + instance setting + group toggle) + Ultimate; no behavior change when the experiment is inactive.

References

• Policy Store: policy list page: https://gitlab.com/gitlab-org/gitlab/-/work_items/604312
• Policy Store: policy details and edit flow: https://gitlab.com/gitlab-org/gitlab/-/work_items/604308
• Policy Store: policy creation flow: https://gitlab.com/gitlab-org/gitlab/-/work_items/604307
• Organization-level counterpart: !249442 (merged)
• Drive the Policy Store editor from the URL: !249038 (closed)
• Toggle system issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/604287
• Epic: https://gitlab.com/groups/gitlab-org/-/work_items/22027

Screenshots or screen recordings

Screen recording (sped up). The bar shows the destination URL for each action — Create new policy → …/policy_store/new, clicking a policy → …/policy_store/<id>/edit (Playwright records the page only, so the browser URL bar is overlaid as a caption):

How to set up and validate locally

1. Enable security_policies_v2, the instance setting, and the group toggle on a top-level group (Ultimate).
2. Visit /groups/<group>/-/security/policy_store. Create new policy navigates to /new and clicking a policy navigates to /:id/edit (editor, pre-filled); Cancel returns to the list.
3. With the experiment inactive (flag/instance/group toggle off) or unlicensed, the routes return 404.

Visual verification

Verified on GDK (security_policies_v2 enabled) on group flightjs, 0 console errors: the create button links to /groups/flightjs/-/security/policy_store/new; each policy links to /groups/flightjs/-/security/policy_store/<id>/edit and the edit page opens the editor pre-filled with the selected policy.

Testing

• Frontend (ee/spec/frontend/policy_store/components/app_spec.js, .../list/list_wrapper_spec.js): list renders by default, editor renders when the initial view is editor and loads the policy by id, cancel navigates to the list, the create button links to the new policy path, and each policy name links to its edit path.
• Request spec extended for new/edit (200 + mount) alongside the existing gating/404 matrix.
• ee/spec/policies/ee/group_policy_spec.rb covers the govern_policy abilities with a role matrix: admins and group owners get all four, auditors get read_govern_policy, and lower roles get none.
• Note: locally the render assertions require a built Vite manifest (absent in this dev env), so those assertions are verified in CI; RuboCop and the routing/gating logic pass locally.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.