This fixed a really tricky bug that led to the wrong keyframe being used due to a floating point rounding error.
Given specific composition start frames and the existing floating point rounding, you could wind up with the following situation:

Keyframe 1 has an endFrame of 48 and an endProgress of 0.095051385
Keyframe 2 has a startFrame of 48 and a startProgress of 0.09505139
The Keyframe.containsProgress check intentionally leaves the upper end of the range open to make it unambiguous that the progress on the boundary of two keyframes should use the latter one.

However, due to this floating point error, there was a gap and if the progress == the endProgress of the first keyframe, it wouldn't match either.

I was able to reconstruct this specific scenario with a unit test and confirmed that this fixed it. However, it is not impossible that there are other scenarios in which this could happen. However, I would rather avoid allocating doubles for everything which is more expensive unless we find a specific repro again