Audit: record reads of sensitive fields and every grant change

The audit log records sign-in, content writes and some membership changes, but not the reads and grants a security review asks about first. The actions recorded through `AuditLog.RecordAsync` cover `auth.*`, content and content type writes, `role.deleted` (`barakoCMS/Features/Roles/Delete/Endpoint.cs:92`), `user.role.*`, `tenant.member.*`, groups and a few deletes. Nothing is recorded when a Sensitive or Hidden field is read, when a role is created or its capabilities change (`Features/Roles/Update/Endpoint.cs`), when an API key is created or revoked, or when a share link is redeemed.

### Why it is too specific

The list grew from the flows that were being built, not from what an auditor asks. A clinic has to answer who opened a patient's notes; an HR team has to show who gave a role the power to see salaries; an agency has to show that a leaked API key was revoked and when.

### The general concept

Two classes of event every such change and read emits: access to data above Public sensitivity (who, which entry, which fields, not the values), and any change to what someone can do (role created or changed with the capability diff, API key created or revoked, share link issued or redeemed). Sensitive read events are grouped per request so a list read is one event.

### Where it lives

Core: audit, sensitivity, roles, API keys and share links.

### Compatibility

Additive. New action names on the existing audit event shape, no stored data migration, no HTTP change beyond more rows in the audit list.

Part of the decision on what a principal is, linked from the umbrella issue. Relates #689, #857.

### Done when

- Reading an entry with a Sensitive field as a role that can see it writes one audit event naming the fields, with a test that fails before the change.
- Changing a role's capabilities writes an event with the before and after lists.
- Creating and revoking an API key each write an event.

Found in the architecture sweep of 15 September 2026.

Start by tracing AuditLog.RecordAsync through the audit, sensitivity, roles, API-key, and share-link flows. Inspect Features/Roles/Update/Endpoint.cs and the role deletion path at Features/Roles/Delete/Endpoint.cs:92, then identify the existing audit tests and add failing coverage for sensitive reads, capability changes, and API-key creation and revocation. Done means the specified events contain the required actors, entries, fields, and capability lists without a data migration.

Written by the indexing model from the issue text.