Scaling: Resource: compose an absolute location in one pass instead of re-deriving it per level

[BioCam]

Hi everyone,

In this PR, we continue improving our Resource modelling system's efficiency, on our way to a more scalable PLR:

Resource.get_absolute_location is now ~7x faster on a typical deck:
it collects the parent chain once and builds at most one rotation matrix per query, instead of rebuilding them at every level.
And the cost no longer grows meaningfully with nesting depth.

Results are bit-identical and fully backwards-compatible.
Where resources are rotated the improvement is smaller but never negative:
2.9x with one rotation high in the chain, 1.7x with every level turned.

	before	after	faster
one query, a well 4 levels down	71 us	10 us	7x
every resource on a loaded deck, 996 of them	70 ms	9 ms	7.5x
building a loaded deck	643 ms	91 ms	7x

The final row highlights a reduced startup cost:
assign_child_resource computes positions as resources are placed, so a loaded STARlet deck builds in 91 ms rather than 643 ms.
-> your scripts will start faster - yeah 🎉💨

Problem

get_absolute_location recursed into its parent, and at each level built two rotation matrices - its own and its parent's - through get_absolute_rotation, which is itself a walk of the same chain.
A resource d levels down built 2d+1 matrices and added up the rotation chain d² times to answer one question.
Each matrix is twelve trigonometry calls and two 3x3 multiplications in pure Python, and on a deck where nothing is rotated, every one of those matrices is the identity matrix, so every multiplication through it returns the offset unchanged.

Changes

• get_absolute_location collects the chain it is positioned through, then walks back down accumulating the position. A matrix is built where a resource turns and left as it was where it does not.
• get_absolute_rotation is called once, at the top of that chain, rather than at every level.
• While the accumulated rotation is zero no matrix is built at all: turning a vector by nothing returns the vector, so the offsets are added directly.

Behaviour: unchanged. Every coordinate is bit-for-bit what the recursion returned, not merely within a tolerance. get_absolute_rotation and Rotation.get_rotation_matrix are untouched; only how often they are called changed.

Scope:
the walk still stops at the first ancestor carrying no location, and the rotation is still taken from the whole tree.
The two methods have never referenced the same frame, and six callers rely on the location-less state; making them agree would move results and belongs in its own PR.

Not addressed / next steps:
repeated queries still recompute from scratch, and every intermediate result is still carried in a Coordinate that rounds three numbers on construction.
Caching absolute locations would need invalidation on every move, which is a much riskier change and worth measuring again only once this and the Coordinate work have landed (i.e. out of scope for this PR).

#1247 moves Rotation to internal quaternion storage, which makes get_rotation_matrix about 17x faster but Rotation.__add__ about 24x slower.
The old recursion leaned on exactly the operation #1247 makes slower, calling __add__ d² times per query, so against current main that PR measures 71 us to 87 us here.
By removing the d² complexity entirely, this PR therefore clears the way for #1247 to be purely an improvement:
in its primary intent, correct rotation composition, and in its side effect on compute cost.

Tests

Two added:
a rotated four-level chain checked against hand-computed coordinates at three anchor points, and a chain hanging from an ancestor that turns what it holds without positioning it.

Checked separately against the implementation it replaces on 670 761 absolute locations - every descendant of all 332 catalog resources constructible from a name alone, placed and rotated, across all 27 anchor combinations - and on 10 330 positions in random trees to depth 7.
Zero differences, at exact equality rather than a tolerance.