Alpha and beta ranges in `OperatingPoint` may need tighter restriction

[camUrban]

Bug Description

OperatingPoint currently restricts alpha and beta to the range (-180.0, 180.0], but this may still be too permissive. Large absolute values within this range may cause silent numerical failures in the solvers.

Location(s): pterasoftware/operating_point.py

Expected Behavior

If testing reveals that extreme alpha or beta values (within the current (-180.0, 180.0] range) break the solvers, the ranges should be tightened with a clear error or warning.

Steps to Reproduce

1. Create an OperatingPoint with alpha or beta set to extreme values within the current allowed range (e.g., 90, 179).
2. Run a steady solver and inspect the results for numerical issues.

Additional Context

This issue is referenced by a TODO comment in OperatingPoint.

[CyberSarvesh]

You can assign me this , i think its a bug I can fix.

[camUrban]

Hi @CyberSarvesh. Thanks for agreeing to take this on. I'll assign the issue to you.

Quick note: I'm not 100% sure that alpha or beta actually need further restriction (hence the question label). The main thing I'm concerned about is possible gimbal lock or transformation issues, which is the reason for range restrictions on some other state-variable angles in the codebase.

One argument that I'd prefer we NOT use to restrict the angles is flow separation. It's true the UVLM can't model flow separation (at least not without serious extensions, and even those are suspect in my opinion), but an alpha-based cutoff would massively oversimplify. This is because flow separation is actually a local, not a global phenomenon, and also depends on the airfoil used, the flapping kinematics, etc.