fix(verify): record a login, not a signup, for confirmed phone sign-ins

[sidgaikwad]

Verifying an SMS code (POST /verify with type: sms) always records a user_signedup audit event, even when the phone is already confirmed and the user is just signing in. Every SMS sign-in by an existing user therefore shows up as a new signup. Reported in supabase/supabase#37583, where the Auth reports in the Supabase dashboard counted repeat phone sign-ins as sign-ups.

The email paths already make this distinction. recoverVerify, used for magic links and recovery, records user_signedup only when !user.IsConfirmed(), and login otherwise.

This PR makes smsVerify do the same: it records login when user.IsPhoneConfirmed() and user_signedup otherwise. ConfirmPhone still runs in both cases, because it also clears the user's one-time tokens. Only the audit action changes.

Tests: a new case in TestVerifyOTPParityPhoneFlows, "sms with a valid code signs a confirmed user in". It mirrors the existing "magiclink with a valid code signs a confirmed user in" case, seeds a confirmed phone, and expects login on both the legacy and one_time_tokens stores. The existing "sms with a valid code confirms the phone" case, whose fixture phone is unconfirmed, still expects user_signedup.

Verified locally (golang:1.27.0-alpine3.23 against postgres:15 initialized with hack/init_postgres.sql, migrations via go run main.go migrate -c hack/test.env):

• The new case passes on both stores. With the verify.go change reverted it fails on both, with expected Action:"login" and actual Action:"user_signedup".
• gofmt -l is clean on the changed files, and go vet ./internal/api passes.
• In a full go test ./internal/api run, the only failure is TestAuth/TestMaybeLoadUserOrSession/Valid_Session_ID_Claim, which fails the same way on unmodified master in my environment. TestExternal cases that reach real OIDC endpoints also fail intermittently with 504 there, on both branches.