Clarify Resource Timing semantics for Early Hints preloads

103 Early Hints can initiate a preload before the final navigation response is available. Resource Timing defines initiatorType = "early-hints", but the expected timing semantics are not fully clear when the Early-Hinted resource is later consumed by the document from the preload cache / HTTP cache.

In particular, for a PerformanceResourceTiming entry with entry.initiatorType === "early-hints" the spec should clarify whether fields like:

• requestStart,
• responseStart,
• responseEnd,
• etc.

must describe:

• the original network fetch started while processing the 103 Early Hints, or
• the later cache/preload-cache read when the document actually consumes the resource.

Existing behaviour

Right now, both Firefox and Chrome report preloads' timings as the cache read rather than the actual Early Hints download (see test page). That makes it difficult or impossible for authors/RUM tools to measure when the Early Hints preload actually happened and how much headstart it had over the main response.

Read the Resource Timing definition of PerformanceResourceTiming and initiatorType="early-hints", then inspect the linked Early Hints test page and compare the reported timing fields in Firefox and Chrome. Done means the specification clearly states whether these fields represent the Early Hints network fetch or the later cache/preload-cache read.