Harden numeric input type handling across geometry/problem setup and add mixed-type coverage tests

[Copilot]

Intermittent failures were traced to inconsistent handling of numeric input types (Python floats/lists vs NumPy scalar/ndarray) in core setup paths. This change standardizes those inputs and adds focused tests to ensure equivalent behavior across scalar, vector, and mixed-type call patterns.

• Input normalization in core constructors/setters

  • SteppedBody.__init__ now normalizes a, d, and slant_angle via NumPy (np.asarray + np.atleast_1d) before length checks.
  • MEEMProblem.set_frequencies now accepts float, scalar ndarray, list, or ndarray and stores frequencies as a 1D NumPy array.
  • BasicRegionGeometry.from_vectors now normalizes a, d, and optional slant_angle to NumPy arrays and validates shape/length consistency early.

• Type-compatibility regression coverage (minimal repetition)

  • Added package/test/test_input_type_compatibility.py with parametrized tests covering:
    • SteppedBody, ConcentricBodyGroup, BasicRegionGeometry, MEEMProblem, MEEMEngine
    • multi_equations methods for:
      • float vs scalar ndarray (scalar inputs)
      • list vs ndarray (vector inputs)
      • mixed list/ndarray inputs
  • Tests compare numerical equivalence across representations rather than duplicating per-type logic.

• Failure modes addressed

  • Scalar SteppedBody construction no longer fails on len(float).
  • from_vectors no longer fails on list inputs with mapped indexing.
  • set_frequencies no longer rejects/incorrectly processes non-ndarray scalar/list inputs.

# Before: type-dependent failures in setup paths
geom = BasicRegionGeometry.from_vectors(
    a=[1.0, 2.0],               # list
    d=np.array([0.5, 0.8]),     # ndarray
    h=np.array(10.0),           # scalar ndarray
    NMK=[3, 3, 3],
    body_map=[0, 1],
    heaving_map=[True, False],
)

problem = MEEMProblem(geom)
problem.set_frequencies(np.array(0.7))  # scalar ndarray accepted