SvelteKit adapter-node vs adapter-static when latency only appears under concurrent requests

I'm designing a SvelteKit deployment for a page whose load function does a small asynchronous operation (roughly 10 ms). Under single requests both deployment options feel identical, but I expect bursts of around 50 concurrent users hitting the same route, and I want to choose the adapter before load testing rather than after an incident.

The documented trade-off I understand so far: adapter-node executes the server render pipeline per request, so CPU-bound rendering can add latency as concurrency grows, while adapter-static pre-renders at build time and serves flat files, keeping response time roughly constant but removing access to request-specific data like cookies, headers, and dynamic query handling without extra client-side fetching.

What I can't resolve is the decision boundary. Assume a recent SvelteKit 2.x and Node 20 LTS on modest hardware.

• At what concurrency level does per-request SSR rendering realistically outweigh the flexibility it provides, and is there a documented way to measure that threshold for my own routes?
• If the page later needs request-specific data, is mixing prerendered static pages with a handful of server-rendered routes in one SvelteKit app a supported configuration, or does it force an all-or-nothing adapter choice?
• Does Svelte's microtask-batched reactivity on the client interact with this decision at all, or is the concurrency latency purely a server-side concern?