Make selection chrome transform-aware

[kostyafarber]

Problem

Selection chrome currently assumes selected objects can be represented by an axis-aligned Rect2D in scene space, then projected to screen space for hit testing. That is good enough while scene nodes are translated only, but it will break once nodes support rotation, shear, skew, non-uniform scale, or nested transforms.

The immediate symptom is in the selection bounding box path: it needs both scene-space and screen-space handles, and it relies on scalar distance conversion such as screenToUpmDistance(px). That scalar shortcut only works for the current uniform camera transform and translated nodes.

Direction

Move selection chrome toward a transform-aware object model:

• Nodes should eventually expose a transform matrix, not only a position.
• Resolved objects should be able to provide local/object bounds plus transforms, or projected outline/corners where bounds are not enough.
• Selection chrome should compute handles from projected corners/edges rather than offsetting an axis-aligned scene rect.
• Hit testing should happen in screen space or through inverse object transforms, not by assuming scene-space axis-aligned geometry.
• Camera projection should remain the screen/scene boundary, using the existing Mat utilities from @shift/geo.

Current temporary slice

For the current node model, it is acceptable to wire Editor.selectionBounds() through resolved ShiftObject.bounds() and keep the selection box axis-aligned. That code should use explicit scene* and screen* names so the temporary assumption is visible and does not reintroduce old glyph-local/upm terminology.

Acceptance sketch

• Selection chrome supports at least translated, rotated, and skewed nodes without misleading axis-aligned handles.
• Pixel-sized handles remain visually stable under zoom and non-uniform object transforms.
• Hit targets match the rendered selection chrome.
• The API does not require tools to manually juggle glyph-local, node-local, scene, and screen coordinates.