Fix biharmonic velocity mixing at boundary vertices

[xylar]

Compute the Laplacian of relative vorticity (Del2RelVortVertex) over the full vertex valid range [MinLayerVertexTop, MaxLayerVertexBot] and clamp each edge contribution to that edge's valid range [MinLayerEdgeTop, MaxLayerEdgeBot], matching VorticityAuxVars::computeVarsOnVertex.

Previously Del2RelVortVertex was computed only over the narrower [MinLayerVertexBot, MaxLayerVertexTop] range (layers where every surrounding cell is active) and summed Del2Edge with no per-edge clamp. The biharmonic velocity tendency (VelocityHyperDiffOnEdge) reads Del2RelVortVertex over the edge range up to MaxLayerEdgeTop, which for a deep edge sharing a vertex with a shallower cell exceeds MaxLayerVertexTop. Those boundary-vertex layers were never computed, so on partial-bottom meshes the biharmonic term was under-computed there. This is a latent correctness bug on its own; on the fill-values branch (#428) the uncomputed layers hold FillValueReal, so the term instead blew up to ~1e45, corrupting NormalVelocity and, through the flux divergence and vertical advection, PseudoThickness and the tracers (surfaced by the new state validation in DRIVER_TEST).

The wider range gives boundary vertices a valid, generally non-zero value from their active edges; inactive edges contribute zero via the per-edge clamp and Del2Edge's zeroed boundary band, so no fill value is read.

Checklist

• Linting
  • Pre-commit run locally
• Testing
  • Add a comment to the PR titled Testing with the following:
    • Which machines CTest unit tests
      have been run on and indicate that are all passing.

[xylar]

Testing

I tested this fix as part of #428

CTest unit tests:

• Machine: chrysalis
• Compiler: oneapi-ifx
• Build type: Release
• Result: All tests passed
• Log: /gpfs/fs1/home/ac.xylar/e3sm_work/polaris/main/build_omega/build_chrysalis_oneapi-ifx/ctests.log

There are no omega_pr tests that catch this particular issue but I will report the omega_pr suite tests including this fix in #428

[xylar]

@sbrus89, please review along with #428 since it fixes the failing CTests you reported.