[hujincalrin41]

Closes #18.

What this does

Operation	Behaviour
Deactivate	Reversible. Grants, owned objects and the email are all left alone, so reactivating gives the account back as it was. Access stops on the next request, since the state is re-read per request.
Purge	Irreversible, and the only thing that frees the email for reuse.
Administrators	Appoint and stand down metastore administrators from the Users page, under the invariant that at least one enabled administrator always remains.

Purge is guarded in the service rather than trusted to the caller: the principal has to be typed
back (the user list mixes people with instance principals, where the wrong row takes a whole
compute instance offline), the account must already be deactivated, you cannot purge your own or
the bootstrap administrator, and a user who owns securables cannot be purged without naming an
heir — those objects change hands as part of the operation.

Fixed along the way

Problem	Origin
PATCH /scim2/Users/{id} carried no authorization annotation, and UnityAccessDecorator lets a method without one through — so any signed-in account could deactivate any other, an administrator included	upstream #500
The administrator password sign-in never consulted the user table, so a deactivated admin still got a session whose every request was then refused — a sign-in that looked like it worked and did nothing	#17
The bootstrap administrator could be deactivated by three separate routes (PATCH, DELETE, PUT) and stripped of its administrator status. Either closes the password sign-in, which is the way back in when the identity provider is unavailable, and no restart repairs the lost privilege	this series + upstream
The PatchOp schema typed value as a boolean, so the UI sent a scalar where RFC 7644 §3.5.2.1 requires an object; the SCIM library rejected it while parsing and the user saw a JSON parse failure instead of a deactivated account	this series
Test servers raced for their port — picked, released, then only bound once Hibernate was up — failing whole test classes with Address already in use on a loaded runner	pre-existing

The last one is why test (Spark 4.1.0) went red on main right after #17 merged:
AuthServiceIdentityResolutionTest failed 1 of 224 in setUp, for a reason that had nothing to do
with that class.

On the bootstrap administrator: UnityAccessUtil#initializeAdmin deliberately allows a deployment
to deactivate it once real accounts exist. That note predates the password sign-in added in #17,
which gave the same account a second job; the two cannot both hold, and the way back in wins.
Granting that account extra privileges is untouched — it locks nobody out.

Tests

server 231 → 252, ui 100 → 109. New: Scim2UserPatchTest, Scim2UserPurgeTest,
MetastoreAdminsTest, BootstrapAdminProtectionTest, users.test.tsx, UsersList.test.tsx, plus
additions to AuthServiceTokenLoginTest and UserActionsDropdown.test.tsx.

Every fix here has a test that was verified in reverse: reverting the fix makes the corresponding
case fail.