Add sign-in-as-user on an administrator's authority

[timujinne]

Why

An administrator supporting a customer has no way to see what that customer sees. Reproducing a "my order list is empty" report means either asking for their password or guessing.

What this is not

It is not a new session mechanism. The multi-account stack already has every primitive this needs — add_authenticated_user/2 appends a session for an already-authenticated user without a password, which is how the OAuth add-account callback works. This adds the authority layer on top: MultiSession.impersonate/2, one controller action, one route.

The rules, and why they are role-based

Deliberately notcan_access_admin_area?/1. That predicate is true for any permission holder — a customer granted a single self-service permission (a client portal, say) satisfies it. Gating on it would have let one customer borrow another customer's account, which is the opposite of the point.

• The root account decides, never the active one. Otherwise an administrator could impersonate a user and, from inside that session, reach someone the administrator could not.
• The root must hold the Owner or Admin role.
• An Owner is never a target. The account that can undo anything must not be reachable by borrowing it.
• An Admin cannot take another Admin — support access is for the people being supported, not sideways between staff. An Owner can, because there is nothing above it to escalate to.
• Self, inactive accounts, a full stack and an account already in the stack are all refused with distinct reasons, so the UI can say which rule stopped it instead of "could not do that".

Every attempt is written to the activity feed as session.impersonated, with actor and target, before the session changes. An impersonation nobody can see afterwards is what would make this dangerous.

The impersonated session joins the existing account switcher next to the administrator's own — they do not lose their own session, and returning is the switcher's existing "switch to" action.

Verification

Exercised against a running host application on real accounts (MultiSession.impersonate/2 directly, so the authority matrix is what is being tested, not the button):

root	target	result
Admin	customer	allowed
Admin	Owner	:target_is_owner
Admin	Admin	:target_is_staff
Owner	Admin	allowed
Owner	customer	allowed
Owner	itself	:self
customer holding a portal permission	another customer	:not_allowed

That last row is the one that matters: it fails on the actor check, which a permission-based rule would have passed.

Nine tests added to test/integration/users/multi_session_test.exs covering the same matrix plus the inactive / already-in-stack / anonymous cases. They are :integration and were not executed here — the environment this was written in has no PostgreSQL for the core suite. Please run them with the suite.

Note for the host

The action is behind the same multi_session_enabled gate as the rest of the stack, so the button should only be offered where that setting is on. There is no UI in this PR: the endpoint is POST /users/session/impersonate/:user_uuid with an optional return_to, so a host can put the button wherever its user list lives.