Enforce float64 internal RBF/grid coefficient handling with wpfloat outputs

[Copilot]

This PR aligns coefficient precision flow across computation and savepoint loading: RBF/grid coefficients are computed/loaded in float64 for numerical stability, then exposed to consumers in wpfloat regardless of wpfloat/vpfloat runtime settings.

• RBF computation precision contract

  • Updated rbf_interpolation to run internal coefficient assembly/solve/normalization in float64.
  • Added explicit cast at return boundary so downstream callers still receive wpfloat.

• Savepoint consumption precision contract

  • Updated read_static_fields(...) to cast interpolation/grid-related loaded fields (rbf_*, geofac_*, c_lin_e, c_intp, e_flx_avg, pos_on_tplane_*, nudgecoeff_e) to wpfloat before constructing diffusion/dycore/diagnostic states.
  • Added a dedicated helper to keep this cast centralized and consistent.

• Focused precision regression coverage

  • Added unit tests validating:
    • returned RBF coefficient dtype follows wpfloat in both double and single precision modes;
    • linear solve path remains float64 under single precision mode.

# internal precision is float64
sol = array_ns.linalg.solve(mat_batch, rhs_batch[..., array_ns.newaxis]).squeeze(-1)

# public contract stays wpfloat
return tuple(coeff.astype(ta.wpfloat, copy=False) for coeff in rbf_vec_coeff)

Original prompt

Please have a look on the computation and the loading from savepoint of rbf coefficients and other grid related coefficients and how the files that produce and consume them are structured towards each other.
How much work is it to have these coefficients always in double (no matter what the types wpfloat or vpfloat are) and return them in wpfloat wherever they are consumed?

Created from VS Code.