fix: offset calculation to handle transformed elements with translateY or translateX in scrollIntoView

[piecyk]

Closes #7716

✅ Pull Request Checklist:

• [ ] Included link to corresponding React Spectrum GitHub Issue.
• [ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• [ ] Filled out test instructions.
• [ ] Updated documentation (if it already exists for this component).
• [ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

[reidbarber]

Thanks for the PR! Is there an existing story we can test this with? If not, could you create a new one?

[piecyk]

Thanks for the PR! Is there an existing story we can test this with? If not, could you create a new one?

@reidbarber I couldn't find an existing story that demonstrates this issue, so I created a simple example with reproducible steps. Please check it out https://stackblitz.com/edit/vitejs-vite-zmdnq3jq.

[uhyo]

@snowystinger Hello! Can we get a chance to get this merged?

I just hit the issue when I tried to use DatePicker inside a virtually scrolled container. I really need this fix.

So the thing we need to prove is that this change is "enough" for our use cases

I understand this concern, but I would like to emphasize that the current implementation is actually broken in some sense. The new getBoundingClientRect-based approach might possibly not be perfect, but its intent looks obvious; it seems clearly better than the current naive offsetLeft/offsetTop accumulation approach.

I'd appreciate if you could revisit this change.

@piecyk Thank you for the fix!