Enable email verification in publish workflow

[HarshMN2345]

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[greptile-apps]

Greptile Summary

This PR refactors email verification enforcement from a build-time feature flag (PUBLIC_CONSOLE_EMAIL_VERIFICATION) to a runtime behavior driven by API error codes. The flag is removed from .env.example, Dockerfile, build.js, publish.yml, and system.ts; a new isVerifyEmailRedirectError() helper centralises detection of user_email_not_verified / console_account_verification_required errors; and both root and console layout load functions are updated to redirect unverified users (or return safe fallback data when already on the verify-email route) without entering a redirect loop.

All seven issues raised in the previous review rounds appear to be addressed:

• (console)/+layout.ts now has a dedicated fast path for unverified users on /verify-email, preventing the re-throw loop.
• +error.svelte now guards the goto call with a URL check.
• Root +layout.ts suppresses verify-email errors when already on the verify-email route instead of re-throwing.
• verify-email/+page.ts no longer depends on consoleVariables from the console layout, removing the unreachable-parent-data problem.

One dead-code path remains in src/routes/+layout.ts's catch block (see inline comment).

Confidence Score: 4/5

Safe to merge after removing the unreachable dead-code branch; all previous loop/redirect issues from prior reviews are now resolved.

All seven previously flagged P0/P1 issues (infinite redirect loops, unreachable parent data, unguarded re-throws) have been addressed. The one remaining finding is a dead-code branch that does not affect runtime behaviour but could mislead future maintainers, warranting a 4 rather than a 5.

src/routes/+layout.ts — dead code in the catch block's 'already on verify-email' fallback.

Important Files Changed

Filename	Overview
src/routes/+layout.ts	Root layout updated to handle verify-email errors from teams/orgs API; early return for the verify-email path is correct, but the fallback branch inside the catch block for "already on verify-email" is unreachable dead code.
src/routes/(console)/+layout.ts	Console layout adds a fast path for unverified users on /verify-email, returning safe fallback data; redirect guards and shouldRedirectToVerifyEmail helper correctly prevent loops.
src/lib/helpers/emailVerification.ts	New helper that detects verify-email error codes both from AppwriteException instances and plain error-shaped objects; covers all known error type strings and the message substring fallback.
src/routes/(console)/+error.svelte	$effect now guards the goto call with a URL check (page.url.pathname !== verifyEmailPath), preventing the previously flagged infinite navigation loop.
src/routes/(console)/verify-email/+page.ts	Removed feature-flag gate (VARS.EMAIL_VERIFICATION); page now works purely based on account.emailVerification status from parent data.
src/lib/stores/billing.ts	Defensive null handling added throughout: makeBillingPlan returns null for null/undefined input, canUpgrade/canDowngrade guard on billingPlan.$id, checkForMissingPaymentMethod early-exits when plans are not loaded, and getPlansInfoStore returns an empty Map instead of null.

_{Reviews (9): Last reviewed commit: "address greptile comments" | Re-trigger Greptile}

[Meldiron]

I think we should no longer have this client-side check. Instead, we relay on server throwing error, of specific type we configured on backend.

When we catch that specific type, we redirect to /verify-email endpoint

[Meldiron]

This whole file feels like overkill. Some methods for 3 line codes, and isVerifyEmailRedirectError feels too complex. In the end, we just need to recognize 1 exception, we dont need anything crazy here.