Function SystemUserFieldAccessLossReason

Why a proposed field-permission state would leave the MJ system user short of its entity-level access, or null when it would not.

Callers pass the rules as they would be after their change — with the edited row's new values substituted, or the deleted row removed. Classifying the changed row on its own cannot answer this question; see the module comment.

Answers null (permits the change) in three cases, each deliberate:

• No system user resolves. A cold UserCache is the normal state during a process's own bootstrap. Blocking an administrator on missing state would be worse than the risk, and FindSystemUserFieldAccessViolations runs at startup precisely to catch whatever slips through here.
• The field is unrestrictable. Primary keys, __mj_ columns and the security-configuration entities are forced open by the aggregation regardless of any row, so no rule about them can restrict anyone.
• The system user has no entity-level read. It is already denied one level up, where the entity permission check has no exemption either, so field rules change nothing for it here.

Note this does NOT gate on EnableFieldLevelSecurity. Rules on a disabled entity are dormant rather than gone — disabling deliberately preserves them — so gating would leave a three-step hole: disable, strip the system user's rows, re-enable.