fix(verify-email): prevent redirect loop on failed verification

[v1nayG]

Fixes #1392

Both updateVerificationEmail and updateVerificationPhone read the user store after invalidate() to build the success notification. At that point the store already reflects the new state, so the ternary produces the opposite message — showing "unverified" after verifying and vice versa.

Capture the intended verification state before the API call so the notification always matches the action. Also disambiguate the messages to say "email has been verified" vs "phone has been verified" when the user has both.

[greptile-apps]

Greptile Summary

This PR fixes two success notification messages in the user verification toggle UI (updateStatus.svelte). It captures newVerification and label before the async API calls so message content doesn't depend on when the reactive $user store re-settles after invalidate().

• Phone verification bug fixed: the original $user.phoneVerification ? 'unverified' : 'verified' (no negation) always displayed the opposite action — e.g., "verified" after marking unverified. The fix uses the pre-captured newVerification flag, which is correct in all cases.
• Email verification refactored: the original !$user.emailVerification ? 'unverified' : 'verified' was functionally correct (the post-invalidation value equals the new value), but the new approach is cleaner and consistent.
• UX improvement: messages now include "email" / "phone" to distinguish which credential was changed.

Confidence Score: 5/5

Safe to merge — the change is a targeted fix to success notification text with no side-effects on API calls, navigation, or data flow.

The phone-verification success message was always inverted due to a missing negation; the fix is correct and well-scoped. The email-verification refactoring is functionally equivalent to what it replaced and improves clarity. No logic paths outside the notification strings were touched.

No files require special attention. The untouched updateStatus() function in the same file uses a similar post-invalidation store read, but it maps correctly and is not broken.

Important Files Changed

Filename	Overview
src/routes/(console)/project-[region]-[project]/auth/user-[user]/updateStatus.svelte	Fixes inverted phone-verification success message and refactors both verification functions to capture the intended new state before the async API call, eliminating reliance on post-invalidation reactive store values

_{Reviews (2): Last reviewed commit: "fix(auth): correct verification alert me..." | Re-trigger Greptile}

[greptile-apps]

Redirect is caught and swallowed on success

In SvelteKit, redirect() works by throwing a special Redirect exception internally. Because the call is now inside the try block, the catch (error) block intercepts it before SvelteKit can handle it. Since the catch does not re-throw, the redirect is silently dropped: the user stays on /verify-email, sees a spurious error toast (with error.message being undefined or an internal Redirect string), and the success toast is also shown — all after a successful verification.

The safest fix is to use a flag and call redirect after the try/catch, or re-throw Redirect instances in catch using SvelteKit's isRedirect helper:

import { redirect, isRedirect } from '@sveltejs/kit';
// ...
} catch (error) {
    if (isRedirect(error)) throw error;
    addNotification({ type: 'error', message: error.message });
}

Alternatively, track success outside the try:

let verified = false;
try {
    await sdk.forConsole.account.updateVerification({ userId: user, secret });
    addNotification({ type: 'success', message: 'Email has been verified', timeout: 10000 });
    verified = true;
} catch (error) {
    addNotification({ type: 'error', message: error.message });
}
if (verified) redirect(303, resolve('/'));