Sensitivity: Sensitive and Hidden access by capability and role id, not the HR role name

A field marked Sensitive is shown only to a role named `HR` unless the field lists its own roles: `barakoCMS/Infrastructure/Services/SensitivityService.cs:144`. SuperAdmin is recognised by the role name in the token, `SensitivityService.cs:49` and `:88`. `FieldDefinition.VisibleToRoles` stores role names, `barakoCMS/Models/ContentTypeDefinition.cs:135`. Because of this, `barakoCMS/Models/SystemRoles.cs:39` has to reserve the names so a custom role cannot pick them up.

### Why it is too specific

The default was written for one scenario, an attendance app with an HR team. A clinic wants Nurse to see patient notes, a school wants Registrar, a bakery has nobody in HR at all. Today each of them has to set `VisibleToRoles` on every field, or create a role literally named HR. Renaming a role quietly changes who can see what, and a custom role granted the right access still sees nothing unless its name is on the list.

### The general concept

Two capabilities, `ViewSensitive` and `ViewHidden`, that any role can be granted. The default policy checks those, not a name. `VisibleToRoles` is keyed by role id, so renaming a role changes nothing. SuperAdmin is identified by id, the way `PermissionResolver` already does it.

### Where it lives

Core: sensitivity, roles and the content type model.

### Compatibility

Released, and stored in every content type document. It needs a migration that resolves stored names to ids, and on read a name that matches no id still resolves by name, so older definitions and imports keep working. The seeded HR role gets `ViewSensitive` by default so existing sites behave the same. Content type JSON keeps accepting names on write, so the HTTP contract does not break.

### Done when

- A custom role named Nurse with `ViewSensitive` sees a Sensitive field, and a test showing that fails before the change.
- Renaming a role listed in `VisibleToRoles` does not change what its holders see.
- Stored name lists are migrated to ids, and a definition that still carries names keeps working.

Found in the too specific sweep of 15 September 2026.

Start with SensitivityService.cs at lines 49, 88, and 144, then inspect SystemRoles.cs:39 and ContentTypeDefinition.cs:135; compare the existing PermissionResolver handling of SuperAdmin. Trace how content type definitions are stored, read, migrated, and exposed through the HTTP contract. Done means capability- and id-based access works, renamed roles retain access, stored names migrate or remain compatible, and the specified regression tests pass.

Written by the indexing model from the issue text.