perf: eliminate wasted API call, afterUpdate overhead, and sequential billing checks

[HarshMN2345]

… billing checks

• Remove unused projects.list() call fired on every console load (result was never consumed)
• Replace afterUpdate with reactive headerAlert subscription to avoid per-render overhead
• Parallelize billing checks with Promise.all instead of sequential awaits
• Fix database.subscribe() memory leak by wrapping in onMount for proper cleanup

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 makes several targeted performance improvements to the console layout: removes an unused projects.list() API call that fired on every load, replaces afterUpdate with a $headerAlert reactive subscription, parallelises four sequential billing checks with Promise.all, and fixes a database.subscribe() memory leak by wrapping it in onMount for proper unsubscribe cleanup.

• +layout.ts: The projects.list() call and allProjectsCount return value are removed entirely — a grep of the full src/ tree confirms no remaining consumers, so the removal is clean.
• +layout.svelte billing checks: checkForUsageLimit and checkForNewDevUpgradePro are now parallelised; paymentExpired and checkPaymentAuthorizationRequired are also batched when requiresPaymentMethod is set.
• afterUpdate replacement: The reactive declaration uses a non-idiomatic comma-expression pattern that may confuse future readers, and fires on initialization unlike the original afterUpdate.

Confidence Score: 4/5

The changes are safe to merge; the only concerns are two readability issues in the Svelte layout file.

The projects.list() removal is verified clean, the onMount subscription fix is strictly better, and the parallelised billing checks are safe because none of the functions share mutable state across await points. The two style concerns do not affect runtime behaviour.

src/routes/(console)/+layout.svelte — the reactive statement at line 325 and the split onMount blocks are worth a second look before merging.

Important Files Changed

Filename	Overview
src/routes/(console)/+layout.svelte	Removes afterUpdate in favour of a $headerAlert reactive statement; wraps database.subscribe in onMount for cleanup; parallelises billing checks with Promise.all. Two style concerns: unusual comma-expression reactive pattern and split onMount blocks.
src/routes/(console)/+layout.ts	Removes the unused projects.list() call and allProjectsCount field; Query import is cleaned up. No remaining consumers of allProjectsCount found in the codebase. Change is safe.

_{Reviews (1): Last reviewed commit: "lint" | Re-trigger Greptile}

[greptile-apps]

Unusual comma-expression reactive pattern

The comma expression (void $headerAlert, ($activeHeaderAlert = ...)) is a non-obvious Svelte pattern. Reading $headerAlert via void purely to register it as a reactive dependency, while performing the actual side-effect in the right-hand operand, is hard to parse at a glance and not idiomatic Svelte. A named reactive block or a dedicated $: if ($headerAlert) form would communicate intent more clearly. There is also a subtle semantic shift from afterUpdate: this reactive declaration fires on component initialization (before any update), whereas afterUpdate only fired after re-renders. On first mount $headerAlert is empty, so getExcluding returns a no-op result — that is harmless today, but the distinction is worth noting for future maintainers.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Two separate onMount blocks in the same component

There are now two onMount calls in this component (lines 253 and 283). While Svelte allows multiple onMount registrations, having two separate blocks for the same component lifecycle event makes the initialization flow harder to follow. The database.subscribe setup could be placed inside the existing onMount block at line 253 to keep all mounting logic in one place.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!