fix: stop inventing an Arcane password and keep the seeded login

[catinspace-au]

The role minted its own admin password, so the credentials on a provisioned box matched neither upstream's documentation nor anything a developer would guess. The login is now exactly what Arcane ships with, and the role sets neither the username nor the password.

What it still does is retire the forced first-login prompt, which is the part worth automating.

Why a password is still submitted

Only a COMPLETED password change clears the flag -- an admin-side user update sets the password and leaves it standing. So the change submits the seeded password as both the old and the new value: the flag drops and the credentials do not move.

Upstream's default strong policy rejects its own seeded password (arcane-admin is twelve characters, but has no uppercase and no digit), so the policy is relaxed to basic first.

Eight characters is the floor regardless of policy. The request schema rejects anything shorter with a 422 expected length >= 8 before the policy is consulted, so a short password is not reachable by configuration at all -- verified against a live instance, not inferred.

Also

• The admin is located by its isGlobalAdmin flag rather than the literal name arcane, so a host whose admin was renamed is still found.
• soe_arcane_admin_password is gone. The one knob left is soe_arcane_password_policy, for putting the character-class requirements back.
• The redundant PUT /api/users/{id} is dropped -- it set the password to the value it already had.

Verified

Destroyed the container, its volume and the stack directory on three hosts, then installed clean. Each came up with:

• username arcane, failed=0, rescued=0, no deploy warnings
• a real login as arcane / arcane-admin returning 200

A 200 on login does not by itself prove there is no follow-on reset page, so this was chased to the source. The root layout renders the change dialog on exactly one condition:

showPasswordChangeDialog = !!(data.user && data.user.requiresPasswordChange && !isAuthPage && !autoLoginEnabled)

data.user comes from userService.getCurrentUser(), which is GET /auth/me. Called with a real session cookie after a real login, that endpoint returns "requiresPasswordChange":false -- so the dialog's only gate is false and it never renders.