Refuse a malformed actor in the two siblings of the credential guard

[timujinne]

Follow-up to the post-merge review of #691, which found the actor-shape hole
closed for admin_update_user_password/3 still open in its two siblings.

The hole

update_user_status/3 and toggle_user_confirmation/2 both ended in:

_system->do_...(user)# unchecked write

That branch exists for callers with no actor — seeds, mix tasks, and
Users.Referrals, which expires an account deliberately without one. It also
swallowed every malformed actor: %{"uuid" => …} decoded from JSON by a host
controller, a bare uuid string, false, 42. Each took the unchecked path.

toggle_user_confirmation/2 is the serious one — its unchecked path reaches
admin_unconfirm_user/1, clearing confirmed_at and locking the target out of
every confirmation-gated page. update_user_status/3 is the same shape with a
reversible effect.

Neither is reachable from core: every LiveView caller passes a real %User{}.
This is host-facing surface, and the same authority-bypass class the series set
out to close.

What changed

Both now use the three-branch shape from admin_update_user_password/3,
including the refusal log. Consistency between the three was the goal — three
functions with one stated rule and three different behaviours is the next bug.

An explicit actor: nil still takes the system path, identically in all three:
Keyword.get/Map.get cannot distinguish it from an absent key. Making it fail
closed is a decision for all three at once and is left out of this PR.

Tests, and an honest accounting of them

The two malformed-actor tests are the ones that carry the fix — verified by
reverting auth.ex and re-running: exactly those two go red.

The six new toggle_user_confirmation/2 tests survive that revert. They are
characterization coverage for a rule that had none — toggle_user_confirmation
appeared zero times in this file before — and they are described that way rather
than counted as regression detection.

A vacuous test, fixed

user_form_authority_test.exs's drift pin had been red on main, and underneath
that it was proving nothing.

It submitted "first_name" => "Harmless" as harness scaffolding while asserting
first_name was unchanged — an Admin editing an Owner may legitimately set it,
so the test failed on its own input. Removing that exposed the real problem: it
poisoned all five identity fields in one payload, Auth.update_user_fields/2
routes them into a singleprofile_changeset, and the generated
"attacker-user_timezone" fails that field's format validation. One invalid
member invalidated the whole changeset, so nothing was written whether the filter
ran or not.

Confirmed by deleting the drop_schema_identity_fields/2 call and watching the
test still pass. It now submits one poisoned-but-schema-valid field per
submission, so no single value can abort the others, and it goes red when the
filter is removed.

Worth noting for the next reader: the "sixth field added to
updatable_profile_fields/0 and forgotten in the filter" drift this test names
is structurally impossible — the filter is derived from that list, not a copy of
it. What it actually pins is that nobody replaces the derived list with a
hardcoded one.

Verification

test/integration/users — 383 tests, 0 failures, no excluded count.
mix format --check-formatted, mix compile --warnings-as-errors,
mix credo --strict (10298 mods/funs) clean.

@version and CHANGELOG.md untouched.