Solution Analysis Options constants scaling

[peterhollender]

When using different frequencies, the default solution analysis options can result in inaccurate calculations of analysis values. Similarly, when the distance units parameter is set to something other than m, the defaults are set in m, so become inaccurate unless they are all set. We should switch to estimated-beamwidth derived defaults, and set any fixed defaults after the distance units have been read.

[vaishnavidesai09]

Reproduction attempt:

• Commit/branch tested: main (886d683)
• Environment: Windows 10, Python 3.14.2
• Steps taken:
  1. Inspected src/openlifu/plan/solution_analysis.py
  2. Checked SolutionAnalysisOptions default field values
• Outcome: Confirmed bug in code — mainlobe_radius, beamwidth_radius, sidelobe_radius, and sidelobe_zmin are hardcoded in meters (e.g. mainlobe_radius=2.5e-3) while distance_units defaults to "m". If a user sets distance_units="mm", these defaults are not rescaled, causing incorrect analysis values.
• Runtime reproduction blocked by missing kwave dependency, but the structural issue is confirmed by code inspection.

(I don't have write access — could a maintainer apply needs-triage:reproduced / needs-info?)

[dblizinski]

@vaishnavidesai09 - this is an important point, thank you. You're correct that the default values for SolutionAnalysisOptions (mainlobe_radius=2.5e-3, beamwidth_radius=5e-3, sidelobe_radius=3e-3, sidelobe_zmin=1e-3) are hardcoded in meters. Since the distance_units default to "m", these defaults are currently correct but could silently become incorrect if a different unit is selected.

Marking this reproduced. Similar to #467, the fix requires an initial design decision whether to store the data generically and convert it during use, or validate and document the unit assumption. I'm forwarding this to our maintainer for guidance on the preferred approach before submitting a PR. I'll provide an update here once a decision is made.

[peterhollender]

I hope I haven't created unnecessary work here... I opened this issue with a solution already in the works, so that I could reference it in the commit message creating the fix. I should be more careful to mention that in the issue body when I'm creating ones like this.