Admin UI and i18n corrections; surface sign-in-as-user in the users menus

[timujinne]

Two related pieces of admin-surface work. They are in one PR because the
impersonation menu item is anchored on the Edit item the first part moves into
that menu, and both touch multi_session.ex and the catalogues — split apart,
the second PR's diff would simply contain the first. Happy to break it up if
you would rather review them separately.

1. Required-field markers, page headers, account-type label

Doubled required markers. <.input> already renders the marker itself
(core/input.ex:87 emits a text-error asterisk when required is set, with
aria-hidden so it is not announced twice). Six labels also hand-appended
" *", so both showed. The literal ones are gone. Organization Name had the
hand-written asterisk but no required attribute, while the changeset does
require it for organization accounts (users/auth/user.ex:491) — it gains the
attribute, so the marker is now real and the browser agrees with the server.

Edit action on the user detail page moves from the breadcrumb bar into the
"..." menu that already sits on the page holding Roles, Confirm Email and
Deactivate. It had been parked in the breadcrumb by the header-deduplication
sweep (208697d) when the in-body header that used to own it was removed. That
was page_action's only call site in the workspace; the attribute and its
:action slot counterpart are now unused, left in place as public API.

Person was a wrong source string, not a bad translation: it named a human
being where the label names a kind of account, the counterpart of
Organization. The msgid becomes Personal, and each locale takes the
idiomatic private-individual-vs-legal-entity term rather than a calque —
Eraisik, Privatperson, Particulier, Particular, Privato, Osoba prywatna. The
stored account_type value stays "person".

The role badge in the admin nav derived its label from
Scope.can_access_admin_area?/1, which is true for Owner, Admin or any single
permission holder. A Client holds client_portal, so clients were labelled
"Admin", and custom roles were flattened into three buckets. The account list
directly below it renders MultiSession.role_label/1 and said "Client" while
the header said "Admin". Both now share that function, reading the names the
scope already loaded in cached_roles rather than re-querying on a component
that renders on every admin page.

2. Entry points for sign-in-as-user

MultiSession.impersonate/2, its authority rules, the controller action and
the POST route all shipped in #672 with nothing in the UI reaching them — a
grep for impersonate across every template returned nothing. This adds the
entry points and changes no rules.

The item appears in the users-list row menu, the card menu, and the user detail
menu. impersonable?/2 decides what to offer by running the same private
predicate the request runs, rather than restating the rules in a template, so
the offer cannot drift from the outcome. Its companion impersonation_actor/1
names the session's ROOT account — the one authority is judged against, which
after an account switch is not the active one — and returns nil unless
gate_allowed?/1 passes, so the item is hidden when multi_session_enabled is
off instead of offering an action that would bounce to the home page.

It is a real POST rather than a phx-click, because it rewrites the session
cookie and a LiveView event cannot; table_row_menu_link therefore stops
dropping method, csrf_token and data-confirm from its :global include.

Translation fixes found along the way

The Estonian catalogue is mechanically healthy — 2158 entries, none empty, none
fuzzy — and still had 38 strings saying the wrong thing. Grouping msgids by
shared msgstr finds the provable class without judging the language: Not set
carried Note's translation, so every unset timezone read "Note"; Current Page
read "Current time"; Field not found read "File not found"; four
Failed to update … messages all read "Failed to update setting";
Cannot delete this user read "Cannot delete the last system owner". Ten more
labels had lost their qualifier, and two pairs of distinct menu entries rendered
identically (Live Sessions / Active Sessions, Dimensions / Dimension Presets).
The rest are word choice and grammar — Healthy read "Tervislik", wholesome as
of food; Override read "ülekate", an overlay; Unnamed contact read as the
imperative "name the contact".

The same check then found twelve of those defects in Russian, fixed there too.
de/en/es/fr/it/pl are clean, so the pairing is specific to et and ru.

Verification

Against a running application rather than compilation alone: the authority
matrix (Owner → Admin/Client/User, never itself; Admin → Client/User, never an
Owner or another Admin; Client → nothing), the rendered menus with each row
present on the page so the negatives are not vacuous, and a real POST — admin →
client makes that account active with a two-deep stack, admin → owner is
refused with the session untouched. Toggling multi_session_enabled live
removes and restores the item.

A GLM security review of the branch traced the controller's three authority
layers and returned PASS; it also caught the feature-flag gap above, which is
fixed here. mix compile --warnings-as-errors and mix format --check-formatted
are clean.

[timujinne]

Code review

Three review passes over this branch — two by GLM (glm-5.2, an elixir-review
and a security-review persona) and one by me. Findings below are the ones that
survived checking against the code; each fix is a commit in this PR.

Fixed during review

Impersonation offered while the feature is off. The menu asked only the
authority rules, which never consult settings, but Session.impersonate/2 opens
with with_gate → gate_allowed?/1, which also requires multi_session_enabled.
With that off the item still rendered and using it bounced the operator to the
home page. impersonation_actor/1 now returns nil unless the gate is open, so
impersonable?/2 answers false for every target — one place, keeping offer and
outcome decided by the same code rather than two condition lists kept in step by
hand. (207cae49)

A query per row on the users list. impersonable?/2 reads roles from the
database, and authorize_impersonation/2 did so three times per call — actor,
target, and the actor again inside staff?/1. On an :if for every row that is
an N+1. Measured with telemetry on a 20-row page: 47 role-assignment queries
before the feature, 108 after. The rule moved into decide_impersonation/4
over role names already in hand; impersonable_uuids/2 reads the actor once and
each target from the :roles preload list_users_paginated/1 already returns.
Same page after: 49. (a94a8d89)

A query per render on the role badge. Same class, caught first:
current_role_badge/1 called role_label/1, which queries, on a component that
renders on every admin page and twice per render — while the predicates it
replaced read scope.cached_roles, already loaded once in Scope.for_user/1.
role_label_from_roles/1 splits the rule from the lookup. (1b722a54)

The new menu strings had no catalogue entries at all, so every non-English
operator saw the label and the confirm() dialog in English — a poor omission
in a branch that also audits translations. Added to the .pot and all eight
locales. (1b722a54)

Verified, not merely compiled

Against a running application:

• Authority matrix — Owner → Admin/Client/User, never itself; Admin →
  Client/User, never an Owner or another Admin; Client → nothing.
• Rendering — with each row actually present on the page, so the negatives
  are not vacuous: offered on the client's row, absent on the owner's and on the
  actor's own. An earlier run of this check was misleading because per_page is
  not overridable by query param and the forbidden rows simply were not on page
  one.
• A real POST — admin → client makes that account active with a two-deep
  stack; admin → owner is refused with the session untouched.
• The feature flag — toggled live: offered, absent, offered again.
• Catalogues — no %{} placeholder differs between msgid and msgstr in any
  of the nine files (a mismatch raises at runtime rather than rendering oddly).

The security pass traced the three authority layers and returned PASS: no
non-staff path reaches the POST; no escalation chain, since impersonation
appends to the stack and the root stays the admin; CSRF enforced through the
host's :browser pipeline, with session-id rotation on success; the template
predicate leaks nothing and enables no enumeration; the widened :global list
is a three-name allowlist admitting no event handlers, with the interpolated
email escaped.

The final pass confirmed the load-bearing detail that <.link method="post">
only takes effect on the href clause, not navigate/patch — the impersonate
links use href while Edit and View use navigate, so there is no silent
no-op — and that the host loads the phoenix_html UJS that converts
[data-method] anchors into real POST forms.

Not addressed here

• The role badge renders system role names in English regardless of locale
  ("Owner"/"Admin"/"User"). Pre-existing — the code this replaces hardcoded the
  same strings — but it sits awkwardly in a PR that also fixes translations. Left
  alone because the account list directly below renders account.role the same
  way, so translating one without the other would introduce a new inconsistency.
• user_details.html.heex still calls impersonable?/2 per render.
  Deliberate: one user is one lookup, and the batching helper exists for lists.
• Audit logging is fail-open — Activity.log/1 is wrapped in
  rescue _ -> :ok while the session mutates before the write, so a logging
  failure leaves a successful impersonation with no audit row. Codebase-wide
  pattern, not introduced here, but worth its own issue for a privileged action.

mix compile --warnings-as-errors and mix format --check-formatted are clean.