core(interactive): also use LCP as bounds in observed metric

[connorjclark]

#16046 changed this audit to use LCP instead of FMP, but incorrectly referred to FCP in a non-user facing doc comment.

Thanks to @csswizardry for pointing this out.

Also updates findOverlappingQuietPeriods, used in the observed metric computation, which was still using FCP as the bounds. Now uses LCP to match Lantern (but I allowed for a fallback to FCP to still get something in the case LCP is missing).

[connorjclark]

@adamraine please look again - I updated the PR since I noticed findOverlappingQuietPeriods (used only in the observed metric) was still using FCP.

[brendankenny]

Not sure if it matters since this is TTI we're talking about (but that applies to making any changes at all, so... :), but seems bad to have this fallback? Makes the metric harder to reason about, discontinuous for an otherwise identical trace depending on if LCP was captured or not, and diverges from the lantern version, which throws if there was no LCP.

[shicoscode]

I agree that the fallback in TTI can introduce inconsistencies. While it might seem like a minor detail, the discontinuity can complicate analysis and make it difficult to accurately compare performance across different scenarios. Perhaps we could explore alternative approaches, such as using a default value: If LCP is not captured, we could set TTI to a default value (e.g., the maximum possible value) to indicate that the metric is incomplete or even introducing a new metric: We might consider creating a separate metric that specifically measures time to first interaction without relying on LCP.