Expose read_value in secrets permissions GraphQL

What does this MR do and why?

This adds the READ_VALUE value to the SecretsManagementAction GraphQL enum. That is the only production change.

It opens the GraphQL door for the "Read value" secrets permission. The persistence and enforcement side already shipped in !240364: the model action, the OpenBao read-only API policy, validate_actions accepting read_value standalone, the readback, and the access-token endpoint. The enum value was the one missing piece, so until now read_value could only be set directly in code or specs, never through the GraphQL API or the UI.

Adding the value also fixes a latent gap. The readback (set_actions_from_capabilities) already emits read_value, but the enum could not serialize it, so querying actions on a value-granted permission would have errored. The enum value closes that.

The active mutations (ProjectSecretsPermissionUpdate and the group equivalent) already accept actions: [SecretsManagementAction], so no mutation or service change is needed. Enum coercion turns input READ_VALUE into the model string read_value.

This unblocks the frontend work in #602726 (add the "Read value" toggle to the secrets permissions UI).

Affected databases

None. No migration and no schema change.

Backward compatibility

Adding an enum value is additive and backward compatible. The READ, WRITE, and DELETE values are untouched, and the current UI keeps working unchanged.

Plan to migrate read to read_metadata

This MR deliberately does not touch the read to read_metadata migration. Here is why it is split out and how it lands.

Today the model already treats read and read_metadata as equivalent on input: management_capabilities maps both to the same OpenBao metadata read capability, and METADATA_READ_ACTIONS accepts both. But the readback still emits the read alias, and the current permissions table renders every action verbatim (actions.map(capitalize).join(', ')). So if we emitted read_metadata on readback now, every existing permission row would show an extra "Read_metadata" chip until the frontend is updated.

So the migration lands with the frontend MR (#602726), in this order:

1. Add READ_METADATA to the SecretsManagementAction enum.
2. Flip the readback (set_actions_from_capabilities) to emit read_metadata instead of the read alias.
3. Update the permissions UI (table and modal) to understand read_metadata.
4. Once the frontend no longer relies on read, a later cleanup deprecates and removes the read alias from the model.

read_value (this MR) is round-trip stable today. read_metadata is only an input alias until step 2, which is why it is grouped with the frontend change.

References

• Related to #602726 (Secrets Manager: add "Read value" permission to the secrets permissions UI)
• Stacked on !240364 (the persistence and endpoint side). This MR targets that branch and should merge after it.

How to set up and validate locally

1. Check out the branch (stacked on eb-direct-access-secret).
2. Run the specs:

   bundle exec rspec \
     ee/spec/graphql/types/secrets_management/permissions/action_enum_spec.rb \
     ee/spec/requests/api/graphql/secrets_management/project_secrets_permissions/update_spec.rb \
     ee/spec/requests/api/graphql/secrets_management/group_secrets_permissions/update_spec.rb \
     ee/spec/requests/api/graphql/secrets_management/project_secrets_permissions/list_spec.rb \
     ee/spec/requests/api/graphql/secrets_management/group_secrets_permissions/list_spec.rb

3. Or via GraphiQL: grant a permission with actions: [READ_VALUE] through projectSecretsPermissionUpdate, then query projectSecretsPermissions { nodes { actions } } and confirm READ_VALUE comes back.

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.