fix(firebase-frameworks): prepare the Next.js server once, not per request

[leoortizz]

Problem

handle() called await nextApp.prepare() on every request. Since Next 13.4.15 that is no longer a no-op in production: each call re-runs the router server initialization, leaking a process-level error listener and rebuilding the render server, until the instance runs out of memory.

Fixes #574.

Fix

Prepare once at module load and await the shared promise — matching the documented custom server example and the existing express, nuxt3 and sveltekit adapters.

Verification

Deployed to Cloud Run at 512MiB. Next 14.2.35, 501 routes, 1500 requests.

Before: listeners grew by one per request, memory grew 0.47 MB per request, and the container was killed twice for exceeding its memory limit.

Memory limit of 512 MiB exceeded with 513 MiB used.
Memory limit of 512 MiB exceeded with 516 MiB used.

After: listeners flat at 3, memory flat at ~144 MB, zero restarts.

[gemini-code-assist]

Code Review

This pull request extracts the nextApp.prepare() call to the module's top level to avoid preparing the Next.js app on every request. However, executing this heavy initialization at module load time can cause deployment failures and slow down cold starts in Firebase/Cloud Functions. The reviewer suggested lazily initializing the preparation promise on the first request instead.