Add first-run lab performance snapshot wizard

Summary

Add a first-run Performance Snapshot Wizard that can run a lab-style before/after comparison for important frontend URLs.

This is intentionally deferred. It should be designed before implementation because the product language and measurement model need to be accurate.

Why this matters

A first-run benchmark can help new users understand what Perform changed and whether basic settings are helping. However, immediate tests should be presented as lab snapshots, not guaranteed Core Web Vitals improvements. Field Core Web Vitals depend on real-user data and cannot prove instant before/after impact on first install.

Proposed approach

• Add an onboarding flow that lets admins select one or more important public URLs.
• Run a baseline lab test using a signed, temporary Perform bypass URL so Perform is active but its frontend optimizations are skipped for that request.
• Enable a conservative Perform preset only after user confirmation.
• Warm cache where relevant before optimized testing.
• Run the optimized lab test against the same URL and environment as closely as possible.
• Use median results from multiple runs instead of a single score.
• Make mobile/desktop strategy explicit.
• Label results as lab estimates and explain variance.

Out of scope for the first version

• Do not claim immediate Core Web Vitals improvement from first-run tests.
• Do not ship or require local headless Chrome inside the WordPress plugin.
• Do not run tests against private/authenticated URLs unless a future remote runner design supports it safely.
• Do not automatically enable aggressive settings just to improve a score.

Safety and privacy requirements

• Signed test URLs must expire and be limited to intended measurement paths.
• Bypass mode must only skip Perform optimization modules for the test request; it must not weaken WordPress authentication or expose private content.
• Avoid storing sensitive URLs, query args, or response details.
• Any external API integration must be opt-in and disclose what is sent.
• Store only bounded result summaries.

Acceptance criteria

• The issue is treated as a design-first 2.0.0 item before implementation.
• A technical design documents the measurement source, bypass model, cache-warm strategy, limitations, and user-facing copy.
• The first implementation supports public URLs only.
• Results clearly distinguish lab estimates from field Core Web Vitals.
• Tests or runtime validation cover expired tokens, disabled bypass mode, optimized mode, cache-warm behavior, and no private URL leakage.

Related context

Related to first-run onboarding work in #108, but this should remain separate until the measurement design is approved.

Start by reviewing this issue alongside the related first-run onboarding work in #108. Produce the technical design before implementation, covering the measurement source, signed bypass model, cache warming, limitations, privacy safeguards, and user-facing copy. Done means the design is approved and the listed validation areas are defined for a public-URL-only implementation.