Perf: speculative variant-chunk preload to parallelise the cold first-render

[kilbot]

Perf follow-up D — speculative variant-chunk preload (parallelise the cold path)

From the first-render deep-dive. Measured cold waterfall (no cache, real flag round-trip):

   34→128ms   welcome.js
  510→1043ms  PostHog config/flags round-trip (ph.wcpos.com)
 1014→1056ms  free-plus.js + .css   ← chunk does not START until the flag resolves
 → first paint ~1.3s

The variant chunk request is serially gated behind the PostHog flag resolution. On a first-ever visit we genuinely must wait for the flag to know the assigned variant (rendering fallback-first would make every first visit a fallback render, which §6.1 excludes from cohorts) — but we can still warm the network in parallel.

Proposal

While resolveFlag() is pending in prepareVariant, kick off a preload of the fallback (free-plus) chunk's JS + CSS (<link rel="preload" as="script/style"> or a fetch()), so that whichever variant is chosen, the most-likely chunk is already in the HTTP cache and injectAssets is near-instant. Options:

• Preload only the fallback (free-plus) — cheapest, covers the common case (and the current flag-disabled state where everyone is fallback).
• Preload both variant chunks (~150KB) — covers either assignment, at the cost of one extra unused download.

Caveats / acceptance

• Preload (not execute) — the chunk must still be injected via the existing injectAssets so it runs exactly once after the runtime is exposed. No double-execution.
• No effect on exposure/SRM accounting (preload is network-only).
• Measure cold time_to_render_ms p90 before/after; ensure no regression to the fallback-rate or landing_error guardrails.
• Consider gating to only when there's no valid assignment cache (warm visits already render instantly after PR perf: instant cached render, branded loading skeleton, trim PostHog #27).

Came out of #27 (instant cached render + skeleton + PostHog trim).