It looks like caretShape(), hitTest(), rangeShape() methods do not take into account the non-zero insets which appear when setting border and/or padding.

To reproduce, run the attached SCCE and observe the stdout:
```
caretShape(0,true) = M0,0 L0,15.311
hitInfo(133,133) = charIndex: 8, isLeading: false, insertionIndex: 9
rangeShape(0,1) = M0,0 L7.554,0 L7.554,15.311 L0,15.311 L0,0
```

This example sets a border of 100 px and a padding of 33 px on the TextFlow.

The first is a result of caretShape(0,true) call, the expected shape should start at x=133 (border + padding), but observed path starts at M0,0 (MoveTo(0,0))
The second line is hitInfo at the upper left corner of the text. Expected hit is character 0, leading=true.
The third line is the path obtained from rangeShape(0,1) which again, is expected to start at (133,133).

The issue can also be seen using Monkey Tester (see the screenshot).

I believe this issue is the root cause of JDK-8334887.

WARNING:
This bug might present a compatibility risk for existing applications which tried to compensate for it by getting the borders and padding from the corresponding Nodes and adding it to each path element (or setting translateX/Y).
It is not clear what might be the best approach - leave the buggy behavior as is and have it fixed (i.e. computed correctly) in LayoutInfo JDK-8341670, or bite the bullet and compute geometry correctly in both cases.

edit 2025/05/02:
I think we should deprecate the buggy methods (but keep them), and add new getX*Shape() with necessary parameters. This would solve the issue without introducing compatibility issues in the existing applications.