Decide whether to report web vitals after a bfcache restore

[logaretm]

The browser SDK does nothing special for web vitals when a page is restored from the back/forward cache. Per the web vitals impact guidance, a bfcache restore should be treated as a fresh page visit with LCP/CLS/INP re-measured. Today we neither re-measure nor report anything for the restored view:

1. Vitals aren't re-measured. Our vendored web-vitals fork (getLCP.ts/getCLS.ts/getINP.ts in packages/browser-utils/src/metrics/web-vitals/) has no bfcache/pageshow reset. initMetric.ts only sets navigationType: 'restore' from document.wasDiscarded (tab discard/reload), which never fires on a bfcache restore since the document isn't reloaded.
2. No span to attach to. browserTracingIntegration starts a pageload span at init and navigation spans via history instrumentation only. It doesn't listen for the pageshow (persisted === true) a restore fires, so no span starts for the restored page.

So we have two options here:

• Exclude (today): underrepresents these fast views, so reported vitals skew slower than reality. Stays comparable to today's numbers.
• Include + tag: report them but tag the web vital / pageload span with a new attribute so restore-driven vitals are filterable downstream. Costs wiring + a new attribute.

Industry has drifted toward include + label (CrUX and Google's web-vitals now attribute bfcache restores).

Open questions:

• Do we want to report web vitals for bfcache-restored views at all?
• If yes, agree on the tagging attribute so the skew stays filterable.

Wiring if we do: start a pageload span on the persisted pageshow, reset + rebind the web-vitals reporters against it, and tag it.

bfcacheMetricsIntegration (#22391) covers hit/miss observability but intentionally doesn't touch web vitals.

[linear-code]

JS-3092