CBC pi_coef_y/pi_coef_z leak in multi-D MUSCL runs (dealloc guards drop `.or. muscl_order > 1`)

[sbryngelson]

s_finalize_cbc_module in src/simulation/m_cbc.fpp fails to deallocate pi_coef_y and pi_coef_z when CBC is used with a MUSCL reconstruction (muscl_order > 1, weno_order == 1) in 2D/3D, because the deallocation guards for the y- and z-direction coefficients only test weno_order > 1, while the allocation guards (and the x-direction deallocation) test weno_order > 1 .or. muscl_order > 1.

Allocation (all three directions consistently use the .or. muscl_order > 1 form):

! x  (line 206)         y  (line 235)               z  (line 265)
if (weno_order > 1 .or. muscl_order > 1) then
    @:ALLOCATE(pi_coef_x(...))   ! / pi_coef_y / pi_coef_z
end if

Deallocation in s_finalize_cbc_module:

! x-direction — CORRECT (line 1400)
if (weno_order > 1 .or. muscl_order > 1) then
    @:DEALLOCATE(pi_coef_x)
end if

! y-direction — BUG (line 1410)
if (weno_order > 1) then
    @:DEALLOCATE(pi_coef_y)
end if

! z-direction — BUG (line 1421)
if (weno_order > 1) then
    @:DEALLOCATE(pi_coef_z)
end if

Impact. For a multi-dimensional case using MUSCL reconstruction (muscl_order > 1, hence weno_order == 1) with CBC boundary conditions on the y/z faces, pi_coef_y/pi_coef_z are allocated (on host, and on device via @:ALLOCATE → GPU_ENTER_DATA(create=...)) but never freed. This is both a host memory leak and, on GPU builds, a device-side data-region leak — @:DEALLOCATE is what issues the matching GPU_EXIT_DATA(delete=...). It also violates the codebase's strict @:ALLOCATE/@:DEALLOCATE pairing invariant.

Fix. Make the y/z deallocation guards match the allocation guards:

if (weno_order > 1 .or. muscl_order > 1) then
    @:DEALLOCATE(pi_coef_y)   ! line 1410
end if
...
if (weno_order > 1 .or. muscl_order > 1) then
    @:DEALLOCATE(pi_coef_z)   ! line 1421
end if

Output-neutral / golden-file-safe. Yes — this only changes cleanup at finalization; no field values or solver output change.

Related to #1459 (general dealloc-pairing enforcement), but this is a specific, concrete leak with a one-line-per-direction fix.

---

_{Filed from a repo-wide code-cleanliness review; locations verified against master @ 40dde5e.}

Code references

• src/simulation/m_cbc.fpp:206 — allocation guard (weno OR muscl), x
• src/simulation/m_cbc.fpp:1400 — x-dir dealloc — correct
• src/simulation/m_cbc.fpp:1410 — y-dir dealloc — bug (weno only)
• src/simulation/m_cbc.fpp:1421 — z-dir dealloc — bug (weno only)