Grant Developer default secrets permissions on project provisioning

What does this MR do and why?

Note: this MR is targeting the specs branch it depends on. Once that gets merged in, this branch will target master.

Project secrets managers now write a default OpenBao policy for the Developer role, next to the Owner and Maintainer policies. The Developer role gets read metadata and create. It does not get update or delete.

The create action grants the OpenBao create capability without update. A Developer can add a new secret. A Developer cannot change a secret that already exists. This is the deliberate difference from the Maintainer default, which gets create and update through the write action.

Group secrets managers still grant the Owner role only. A new spec asserts the Developer role gets no default policy for groups.

Owners can remove or change the Developer row at any time, through the existing permissions UI and GraphQL mutations. Removal deletes the OpenBao policy right away.

Backward compatibility and rollout

• Only newly provisioned projects secret managers get the Developer default. Existing projects with active SM are not backfilled (permissions have to be manually granted)
• Provisioning returns early when the secrets manager is already active, so a re-provision never adds the default retroactively. A separate backfill would be needed if product wants this for existing managers. This matches the decision taken for the Maintainer default.
• No database changes and no migrations.
• No new feature flag. The feature stays behind the existing secrets_manager flags.
• Rollback is a plain revert. Managers provisioned while this is live keep the Developer policy until an Owner removes it.

Tests

Specs run against real OpenBao.

• New provision shared examples for the Developer default. The project spec asserts create, list and scan on the data path, read, list and scan on the metadata path, and list on the detailed metadata path. The group spec asserts the Developer role gets no default policy.
• The project permissions list service spec expects the Developer row with the actions create and read.
• GraphQL projectSecretsManager.userPermissions: the Developer default returns readMetadata and createSecrets true, with updateSecrets and deleteSecrets false. After an Owner deletes the Developer row, all four are false.
• End to end: a Developer with no explicit grant creates a secret. A Developer update is rejected.

Docs

• doc/user/permissions.md: the project Secrets Manager table marks the Developer column for "Read secrets metadata" and "Create secrets (without update permission)". A new footnote records that the default applies to secrets managers enabled in GitLab 19.5 and later, and that Owners can remove or change it.
• doc/ci/secrets/secrets_manager/_index.md: a paragraph under project permissions describing the Developer default, including that create does not include update, plus a 19.5 history entry.

References

• Implements #623438 (closed)
• Depends on !259130 (merged)
• Builds on !253998 (merged) which added the Maintainer default and the shared default role policy code
• Unblocked by #623435 (closed) which added the create-only action
• Part of the epic gitlab-org#22561 (closed)

Screenshots or screen recordings

Not applicable. This is a backend and docs change with no UI changes.

How to set up and validate locally

1. Start OpenBao in your GDK.
2. As a project Owner, enable Secrets Manager for a new project and wait for it to become active. A project whose secrets manager is already active will not show the new default, because default policies are written only at provision time.
3. Go to Settings > General > Visibility, project features, permissions > Secrets manager. The Roles tab shows Owner, Maintainer and Developer. The Developer row reads "Read metadata, Create".
4. Sign in as a Developer of the project. Open the project Secrets page. Create a secret. It succeeds.
5. Edit that secret as the Developer. It fails.
6. As the Owner, remove the Developer row. Reload the Secrets page as the Developer. It returns 404.
7. Enable Secrets Manager for a group. Its Roles tab still shows the Owner row only.

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.