feat: align the beam-aligned coordinate system with the incident beam

[SimonHeybrock]

Stacked on #724 — its tests need the corrected drop direction.

The beam-aligned coordinate system defines the z-axis by projecting the incident beam onto the plane perpendicular to gravity, and pins the y-axis antiparallel to gravity. It is therefore aligned with the incident beam only when the beam is perpendicular to gravity. Otherwise phi is the azimuth about the horizontal projection of the beam, which is not a scattering azimuth, and the transverse components of the scattered beam keep part of the beam's inclination.

The z-axis now is the incident beam, and the y-axis is derived from it. The x-axis is unchanged — it is horizontal and perpendicular to the beam under either definition. The two definitions agree exactly for an incident beam perpendicular to gravity, so nothing in use today changes; the existing tests pass untouched.

The new round-trip test states the intent: send a neutron away from the sample at a known two_theta and phi relative to a tilted incident beam, let it fall onto a detector, and require that both angles come back.

scattering_angle_in_yz_plane continues to reject non-orthogonal incident beams. Its γ is measured from the horizontal plane rather than from the incident beam, so this generalization does not carry over — the two techniques genuinely want different references, and they coincide only in the orthogonal case.

Why

SANS applies a beam center: the beam passes through the sample but its direction, set by the collimation, deviates from the nominal source–sample axis. The natural expression of that is to pass the actual direction as incident_beam. Today that silently produces a wrong phi/Qx/Qy for any vertical component of the beam center, so ESSsans instead shears every pixel's scattered beam: _scattered_beam_with_beam_center in scipp/ess#729. That is exact along the beam and approximate elsewhere, and it is 30 lines of subtle code that this change removes.

@jl-wynen — flagging you directly, since this changes a documented convention you defined. The alternative is to make scattering_angles_with_gravity raise for non-orthogonal beams the way scattering_angle_in_yz_plane already does, which is self-consistent but leaves SANS with the shear. I think generalizing is better: phi is only ever used as an azimuth about the beam, and refusing leaves a public frame that provably cannot describe the case it is asked about. What do you think?

[jl-wynen]

I'm not sure it is a good idea to tilt the coord system. This makes it less intuitive to reason about where components are placed. Can we adjust how we compute phi instead?

[SimonHeybrock]

I'm not sure it is a good idea to tilt the coord system. This makes it less intuitive to reason about where components are placed. Can we adjust how we compute phi instead?

Are we really tilting the coord system? What is computed here is (as far as I can tell) only used for computing scattering downstream, not relating to other component positions. And the naming is already beam_aligned_unit_vectors and BeamAlignedUnitVectors, not CoordSystem.

[jl-wynen]

@SimonHeybrock I just realised that the documentation is now inconsistent. In the coordinate transformation and the beamline docs, we show this image directly above the equations you changed:

This needs to be updated. Or we isolate the new coord system in the gravity correction functions.

[jl-wynen]

Also, the definition of $\phi$ no longer matches the lab frame, but the beam aligned coord system. That could be confusing.