EC2 PHC / ClockBound — timestamp-bound pairing and TSC drift assumptions

We are reviewing a proposed PHC-only time-validation integration based on ClockBound commit 4072097bab61e516c15377a581b649df49852021. This is a design review, not a production incident.

Please provide documentation or route these questions to the relevant ENA, ClockBound, or EC2 time-service maintainers:

ENA documentation states that each PHC timestamp request retrieves and caches its error bound. Under a single-reader configuration, what conditions ensure that a subsequent phc_error_bound sysfs read corresponds to that timestamp? Please cover concurrent requests, timeouts, driver resets, cache invalidation, and whether retaining the PHC device index implies any continuity guarantee.
ClockBound defines MAX_DISPERSION_GROWTH_PPB as 15,000 and refers to CPU specification tolerances. What documented platform assumptions support this bound for the guest TSC, including frequency changes, maintenance, and the permitted projection horizon?
What VMClock disruption, status, and leap-indicator guarantees are available on supported EC2 platforms? In particular, which signals reliably invalidate a PHC-derived UTC interval across discontinuities, and when are those signals observable?

Please identify applicable driver, kernel, instance-platform, and ClockBound versions. Where no guarantee exists, please state the supported assumptions and limitations explicitly.

We are requesting the upstream input contract, not certification of our proposed modification.