fix(HillasIntersection): use geometry frame focal length for CameraFrame reconstruction

[STSpencer]

## Summary

HillasIntersection._predict builds a CameraFrame for coordinate transforms using the telescope's equivalent_focal_length when processing CameraHillasParametersContainer input. However, the camera geometry — and therefore the Hillas parametrisation itself — is defined with the focal length chosen at read time (SimTelEventSource.focal_length_choice, which defaults to FocalLengthKind.EFFECTIVE). The effective and equivalent focal lengths differ by ~4–5% for typical CTA telescopes (e.g. LST: ~29.3 m effective vs 28 m equivalent).

Because the reconstructed angular position is proportional to camera_position / focal_length, using the wrong value introduces a plate-scale error. This error grows with the distance of the image from the camera centre. High-energy showers produce large, off-axis images far from the centre, so they are disproportionately affected — degrading angular resolution exactly at high energies.

The sibling reconstructor HillasReconstructor already handles this correctly by reading camera.geometry.frame.focal_length.

Change

# Before
focal_length = self.subarray.tel[tel_id].optics.equivalent_focal_length

# After
focal_length = self.subarray.tel[tel_id].camera.geometry.frame.focal_length

This reads back the focal length that was actually used when building the camera geometry frame, regardless of which focal_length_choice was configured — making HillasIntersection consistent with HillasReconstructor and with the parametrisation frame.

Notes

• Only affects reconstruction from CameraHillasParametersContainer (i.e. ImageProcessor.use_telescope_frame=False). The default telescope-frame path is unaffected as it operates directly in angular coordinates.
• All 62 reco tests pass.
• ruff format --check and ruff check pass clean on the changed file.
• SonarQube analysis reports 0 security issues on the changed file; no new code smells are introduced.

[kosack]

That is definitely a bug! I suspect that is one of the reasons why HillasIntersection never gave as good results as HillasReconstructor. Maybe we should consider just dropping HillasIntersection altogether? Is it worth maintaining two versions of the same algorithms?