Permissions: readable and writable field sets on a permission rule, with sensitivity as audience defaults

Two access systems decide what a caller sees and they do not compose. A `PermissionRule` has only `Enabled` and `Conditions` (`barakoCMS/Models/PermissionRule.cs`), so a rule can say which entries a role may update but not which fields. Field visibility is separate: `SensitivityService` hides Sensitive fields from everyone outside a role list, defaulting to HR (`barakoCMS/Infrastructure/Services/SensitivityService.cs:144`), and it has no notion of own record.

### Why it is too specific

It fits read-all or read-nothing staff. A school wants a teacher to update attendance but not grades on the same record; a clinic wants a patient to read their own notes and nothing of anyone else's; an agency wants a client editor to change copy but not the SEO fields. None of these can be expressed as a rule or as a sensitivity level alone.

### The general concept

A permission rule carries optional readable and writable field sets beside its condition. Sensitivity levels become the default field sets for audiences that have no rule, so existing types keep working and a rule can narrow or widen them for one role, with or without a condition.

### Where it lives

Core: permissions, sensitivity and content writes.

### Compatibility

Released, stored in role documents. Field sets are optional, so every stored rule means what it means today. A write to a field outside the writable set is a new 403 only for roles that opt in. Builds on #883, which moves sensitivity to capabilities and role ids first.

Part of the decision on what a principal is, linked from the umbrella issue.

### Done when

- A role with update on a type but a writable set without `grade` gets 403 writing `grade` and succeeds writing `attendance`, with a test that fails before the change.
- A rule with an own-record condition and a readable set shows those fields for the owner only.
- A type with no field sets behaves exactly as today.

Found in the architecture sweep of 15 September 2026.

Start with barakoCMS/Models/PermissionRule.cs and barakoCMS/Infrastructure/Services/SensitivityService.cs:144, then review the capability and role-id changes in #883. Add tests for writable-field enforcement, own-record readable fields, and unchanged behavior when no field sets are configured; done means the listed 403, success, owner-only visibility, and compatibility cases pass.

Written by the indexing model from the issue text.