Decide whether to report web vitals after a bfcache restore

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](https://web.dev/articles/bfcache/#core-web-vitals), 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.