Static rendering vs hydration for edge-deployed SvelteKit pages with runtime-dependent content

When deploying a SvelteKit application to an edge platform, pages that incorporate runtime-dependent values—such as timestamps, user-specific data, or feature flags evaluated only on the server—create a tension between two documented rendering modes.

Enabling the default hydrate: true preserves client-side interactivity but risks hydration mismatches when the server-rendered markup diverges from the client's initial render, surfacing as deployment-time errors in the logs. Disabling hydration with hydrate: false guarantees a static HTML payload that never mismatches, yet it defers all interactivity to a later client-side re-hydration step, increasing time-to-interactive for dynamic components.

SvelteKit 1.5 introduced finer-grained prerender controls, but they do not resolve the fundamental trade-off for pages that must reflect server-only state at request time. The documentation acknowledges the choice without prescribing a deterministic rule, leaving the decision to the developer.

Which rendering mode should be chosen for an edge-deployed page that reads a server-only configuration value at request time, requires a button to remain interactive on first load, and must avoid hydration-mismatch failures in production logs?