Consider adding DetectorTwoTheta node type to ess.reduce

Context

In scipp/ess#462 we found that assemble_output_calibration in ess.powder had a false dependency on CorrectedDetector when it only needed geometric quantities (Ltotal and two_theta).

ess.reduce already provides DetectorLtotal and MonitorLtotal as sciline node types computed from EmptyDetector + beamline geometry. However, there is no equivalent for two_theta.

As a fix, we introduced DetectorTwoTheta in ess.powder (scipp/essdiffraction#250 — PR pending). This mirrors the pattern of DetectorLtotal:

class DetectorTwoTheta(sciline.Scope[RunType, sc.Variable], sc.Variable):
    """Scattering angle (two-theta) for each detector pixel."""

with a provider that computes it from EmptyDetector + source/sample positions + gravity using the scippneutron beamline coordinate transformation graph.

Question

Should DetectorTwoTheta live in ess.reduce alongside DetectorLtotal? The argument for:

• Symmetric with DetectorLtotal — both are purely geometric, per-pixel quantities derived from the same inputs
• Other instrument packages (not just powder) may need two_theta as a standalone node

The argument against:

• two_theta is only meaningful for scattering instruments, while Ltotal is universally needed (e.g., for time-of-flight computation)
• May be premature to generalize before more instruments need it

For now it lives in ess.powder. Moving it later would be straightforward.

Start by comparing the existing DetectorLtotal and MonitorLtotal node types in ess.reduce with the DetectorTwoTheta implementation currently in ess.powder. Review the scippneutron beamline coordinate transformation inputs and the linked pending PR, then determine whether the geometric node belongs in ess.reduce; done means reaching and documenting a repository decision.