fix(login): use system identity in ResetTemporaryPassword mediator call

[The127]

Summary

• /logins/* deliberately skips authentication.Middleware (the login flow is pre-authentication; the login token in the URL is the capability, no Bearer token yet). So the request context carries no CurrentUser.
• ResetTemporaryPassword is the only login-flow handler that issues a mediator command (commands.SetPassword). PolicyBehaviour.evaluatePolicy calls authentication.GetCurrentUser unconditionally and panics with "current user not found".
• Inject authentication.SystemUser() into the mediator-call context: PolicyBehaviour short-circuits to Allowed, SetPassword runs. The login token plus the LoginStepTemporaryPassword guard are the proof of authority; the server is acting as a trusted system actor on the user's behalf, which is exactly what authentication.SystemUser() exists for.

Why this was latent

Until v0.5.2 the access-request approve flow in keyline-saas-admin-api was 401-blocking on POST /api/virtual-servers/portal/users (system-admin role had no user:create permission). Once v0.5.2 fixed that, the first portal user with a temp password reached the reset-temp-password step in production, and the panic surfaced.

Test plan

• go build ./... clean
• After release: complete an access-request approve, log in with the temp password, reset to a real password — should succeed (currently 500s with handler panic)

Follow-up worth considering

• No login-handler tests exist today (internal/handlers/login_test.go is missing). The login flow is exercised end-to-end nowhere. Worth a focused e2e test pass for the temp-password flow.