Permissions: caller attributes in conditions from a per-tenant member profile

A permission condition can refer to exactly one thing about the caller: their user id. `ConditionEvaluator` substitutes `$CURRENT_USER` (`barakoCMS/Infrastructure/Services/ConditionEvaluator.cs:127`) and the SQL compiler does the same (`barakoCMS/Infrastructure/Services/PermissionPredicateCompiler.cs:328`). Nothing else about the caller, such as a department, a branch or a class, can appear in a condition.

### Why it is too specific

It fits "a user owns what they created". A school's HR creates the records for a teacher, so the teacher is not the creator and cannot see them; a bakery chain wants a branch manager to see their branch's orders; a clinic wants staff to see patients of their ward. Each needs an attribute of the caller, not just their id.

### The general concept

A per-tenant member profile with fields the tenant defines (for example `branch`, `ward`, `personRecord`), and conditions that refer to them as `$CURRENT_USER.`. Both the in-memory evaluator and the predicate compiler resolve the same variables, so authoring and delivery agree.

### Where it lives

Core: membership, conditions and the predicate compiler.

### Compatibility

Additive. `$CURRENT_USER` alone keeps meaning the user id. Stored rules do not change. An unknown profile field resolves to no match, never to a match.

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

### Done when

- A rule `branch eq $CURRENT_USER.branch` returns only the caller's branch entries through both the evaluator and the compiled predicate, with a test that fails before the change.
- A caller with no value for the field matches nothing.
- Existing `$CURRENT_USER` rules return the same results.

Found in the architecture sweep of 15 September 2026.

Start with ConditionEvaluator.cs:127 and PermissionPredicateCompiler.cs:328, then trace how membership and tenant profile values are represented. Done means both paths resolve $CURRENT_USER. consistently, missing values never match, existing $CURRENT_USER rules remain unchanged, and tests cover branch filtering and the no-value case.

Written by the indexing model from the issue text.