The finding of DM-34065, which confirms https://confluence.lsstcorp.org/display/LTS/Closed-Loop+Simulation+with+Non-Zero+Camera+Rotation+Angle was that rotTelPos does not change the angle between the camera and the M1M3 assembly. As https://sitcomtn-003.lsst.io/#camera-rotator explains, there are various ways to address nonzero camera rotator angle, and one is implemented in ts_ofc  (https://github.com/lsst-ts/ts_ofc/blob/develop/python/lsst/ts/ofc/camrot.py used in https://github.com/lsst-ts/ts_ofc/blob/f33ffaf1f84dcdd7e7d526118c647cffcc7bf4ef/python/lsst/ts/ofc/ofc.py#L232 ).

The goal of this ticket is to rotate the calculated grid surface for M1, such as `randSurfInM` in https://github.com/lsst-ts/ts_phosim/blob/2d3ab7a18d5ba89c719a232a4beba19f8443724e/python/lsst/ts/phosim/telescope/M1M3Sim.py#L631 . It would be physically correct to rotate M1, M2, and M3 to "fake" the camera rotation. However, the main perturbation terms come from M1, and dominates those of M2,M3. So to test the principle, we try first only rotate M1.  Then inspect the generated donut images and  OPDs, and compare to the un-rotated images. Check whether retrieved Zernikes are rotated or not.