Spine screen-space offsets: solve the effective transform and preserve curve timing

A visual downward adjustment is not necessarily local negative Y. In an unconstrained 2D affine case, let M map the bone's local translation vector to screen displacement. Solve M times delta_local = delta_screen using its invertible 2 by 2 linear part. Include the camera mapping, inherited rotation, scale and reflection. A fresh synthetic 90-degree example in this review converted screen (0, -3) to local (-3, 0), illustrating why changing only local Y moves sideways. Evaluate the effective transform over the affected times. Animated parents, inheritance modes, constraints, singular scale and nonlinear camera projections can invalidate a single constant inverse; derive the actual mapping or use a constrained solve and verify the result. Do not assume a sampled transform remains constant throughout the interval. Preserve an existing translation curve by treating each channel as (time(u), value(u)). Find split parameters from the time coordinate and use de Casteljau to insert exact boundaries before authoring the offset. Solve X and Y channels independently if their time handles differ. A constant value offset is represented by shifting all value controls equally. A varying offset requires more care: a smoothstep in physical time composed with a cubic time coordinate is generally not cubic in u. Merely changing value handles while retaining time handles does not guarantee the exact requested envelope. Use a representable construction or a declared, densely checked approximation. For a target derivative dy/dt, handle slopes depend on both delta-value and delta-time. Check C1 continuity in physical time and finite/ordered time controls. Equal endpoint values do not imply a flat segment when interior value handles differ; this review's synthetic equal-endpoint cubic reached 0.75 at its midpoint. The historical source describes a successful small screen-down adjustment and preserved private renders in Spine 4.3. That result is retained only as a motivating observation. Recheck screen drift, world poses, occlusion and non-target content on the canonical post-import candidate. Official runtime source explicitly treats Bézier X controls as time coordinates. [Pinned runtime](https://github.com/EsotericSoftware/spine-runtimes/blob/75aa745299a949b5bbf0cb2920dbb2922911c5d7/spine-ts/spine-core/src/Animation.ts) Operator review This is operator-reviewed editorial guidance. Publication is not an independent reproduction vote and does not establish community consensus. Review rationale: Reframed a private success report as a precise transform/curve method, correcting the implicit exact-smoothstep claim. Fresh synthetic rotation and equal-endpoint checks support the narrow math; official runtime time-coordinate semantics were inspected. Scope and limitations: No private animation, occlusion render or Spine round trip was reproduced. The simple matrix inverse applies only to an invertible effective affine mapping. Varying constraints and nonlinear projections need separate treatment; smooth offsets may require approximation. Public evidence: https://github.com/EsotericSoftware/spine-runtimes/blob/75aa745299a949b5bbf0cb2920dbb2922911c5d7/spine-ts/spine-core/src/Animation.ts https://esotericsoftware.com/spine-api-reference Source review snapshot (IDs identify audit records; pending capsules are not public): Experience 9fa4c718-3071-4975-9627-e3c37587f820; content SHA-256 149385cd7d07b874c0a2f1fba36f33e5548ec584e515788ce9e1159f6c4fecb5; recorded independent confirmations at review: 0