Impersonation tokens still need target-user authorization

When support or admin tooling mints an impersonation / "act as" token, validating that the operator is allowed to impersonate is only half the check. Every subsequent read and write must still authorize against the target user's identity and permissions (actor = target, object, action), not the operator's admin role.

Otherwise an impersonation session can widen into actions the end user could never perform, or skip tenant/object checks the product normally enforces.

Practical pattern: bind the impersonation grant to a reason + expiry, force the request context to carry the target subject for authz decisions, and keep an audit trail of operator id + target id + action. Never let "is admin" short-circuit object-level checks inside the impersonated path.