Secrets Manager: Add "Read value" permission to the secrets permissions UI

Problem

Non-CI/CD secret access (#594090) adds a new read_value permission to the secrets permission model so a principal can read a secret's actual value (not just its metadata). The backend wiring lands in #594090, but users cannot grant the new permission until the UI exposes it.

Until then, the access-token endpoint works at the backend / API level but is not usable in practice, because there is no way for an Owner to grant read_value through the UI.

Background: how UI permissions map to OpenBao

Each permission row a user sets for a principal becomes an ACL policy in OpenBao. Each option toggles a capability on a path. There are two paths: a metadata path and a value (data) path. The metadata-vs-value distinction is exactly which path the read capability lands on.

UI permission	Action (model)	OpenBao capability	Path
Read metadata (today's "Read")	read_metadata	read	metadata path
Write	write	create + update	value path
Delete	delete	delete	value path
Read value (new)	read_value	read	value path

Proposal

1. Expose the new read_value action in the secrets permission GraphQL mutations and types (permissions enum, create/update permission, permission type).
2. Add a "Read value" option to the secrets permission UI, for the same principal types already supported: a specific User, a Role (Reporter and up), a custom Member Role, or a Group.
3. Clarify the labeling so "Read value" (the actual secret value) is clearly distinct from the existing read-metadata permission. Coordinate the exact wording with technical writing. Today's "Read" should be relabeled to "Read metadata".
4. Enforce in the UI that "Read value" requires read-metadata (you cannot read a value for a secret you cannot otherwise see). Additive, not a replacement.

Permission action transition (read -> read_metadata)

The backend MR (#594090) lands the action change additively, so it can ship first without a lockstep deploy:

• Backend accepts both read and read_metadata on input (aliases, both mean read-on-metadata-path).
• Backend readback keeps emitting read for now, so the current UI is untouched.
• Backend adds read_value.

This frontend MR completes the migration (FE and BE ship together, so the deprecation removal happens here, not a separate follow-up):

• Send and display read_metadata instead of read.
• Add read_value handling.
• Remove the deprecated read: stop sending it, flip backend readback to emit read_metadata, and drop the read input alias.

Scope

• In scope: GraphQL exposure of read_value, the secrets permission UI changes, and completing the read -> read_metadata migration (including removing the deprecated read alias).
• Out of scope: the permission model, OpenBao policy wiring, the auth role, and the endpoint (all in #594090). This issue does not block #594090 from merging; it makes the feature usable for end users.

Related

• #594090 (endpoint + backend wiring, where read_value and the read_metadata alias are defined)