fix: use world matrices in getSpaceFromAncestors for XRLayer positioning

[myers]

Summary

XRLayers were incorrectly positioned when inside components that override updateWorldMatrix (e.g., UIKit's Content component which applies layout transforms like globalMatrix and childrenMatrix).

The bug: Compositor layers appeared at wrong positions while fallback meshes rendered correctly.

Root cause: The previous implementation accumulated local matrices via premultiply(object.matrix), which missed any custom transforms applied during updateWorldMatrix().

The fix: Switch to using matrixWorld directly after calling updateWorldMatrix(true, false), ensuring any custom matrix computations are properly reflected in XRLayer positioning.

Test plan

• Tested XRLayers inside UIKit Content components on Quest 3 hardware
• Verified both compositor layers now appear at correct positions (matching fallback meshes)
• Tested standalone XRLayers (not inside UIKit) still work correctly

[bbohlender]

thanks, the PR looks good, but as explained before using "blendTextureSourceAlpha" and transparency as synonym is not correct

However, I do not see a reason to change so much:

the offset calculation could still happen inside getXRSpaceFromAncestorsRec limiting the fix to this one function (I prefer minimal PRs or a reason why a bigger change is necassary)

[myers]

thanks, the PR looks good, but as explained before using "blendTextureSourceAlpha" and transparency as synonym is not correct

Sorry about that it was a zombie commit 🧟

[myers]

@bbohlender I think this is ready for your review again.

[bbohlender]

This should be executed in getSoaceFromAncestors or else we would immediately conflict with the requirement

In this function we do not know that targetObject is the child of object but in getSpaceFromAncestors, we know this so executing upateMatrixWorld once is enough

[myers]

thank you for clarifying, I misunderstood what you had said on the previous version.