IBM/IC patch geometry IDs (2-21) are bare integers across 4+ files with no named-constant set

[sbryngelson]

Patch geometry types are dispatched on bare integer IDs (geometry == 8 = sphere, == 2 = circle, == 21 = STL, etc.) in if-ladders spread across pre_process and simulation. There is no named-constant set for these IDs — src/common/m_constants.fpp only mentions geometry numbers in comments (e.g. "geometry 14") but defines none.

Sites:

• src/simulation/m_ib_patches.fpp:45-79 — 3D ladder (8 sphere, 9 cuboid, 10 cylinder, 11 3D airfoil, 12 3D model) and 2D ladder (2 circle, 3 rectangle, 4 airfoil, 5 model, 6 ellipse).
• src/simulation/m_compute_levelset.fpp:38-68 — same IDs inside GPU_PARALLEL_LOOP regions.
• src/simulation/m_ibm.fpp:1061-1062 and 1128-1137 (each branch annotated with the shape name in a comment — underscoring that names are wanted).
• src/pre_process/m_icpp_patches.fpp:64-146 — dispatch covering 1-6, 8-14, 16-21 (8 sphere, 21 STL, etc.).

Why it's friction: the mapping ID→shape lives only in comments and reviewer memory; the same numbers are repeated across 4 files with no single source of truth. Adding/renumbering a geometry means hunting every ladder.

Fix: introduce a named-constant set (e.g. in m_constants.fpp: GEO_IB_CIRCLE = 2, GEO_IB_SPHERE = 8, GEO_MODEL_STL = 21, …) and replace the literals. Same values → golden-neutral.

Dedup note: distinct from #1451 ("STL and Airfoil Memory Structs") and #1478 ("Unify ICPP STL Implementation"), which are about STL/airfoil memory/IO structs, not geometry-ID constants.

---

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

Code references

• src/simulation/m_ib_patches.fpp:45-79 — geometry-ID ladders
• src/simulation/m_compute_levelset.fpp:38-68 — geometry-ID ladders
• src/simulation/m_ibm.fpp:1128-1137 — annotated geometry IDs
• src/pre_process/m_icpp_patches.fpp:64-146 — patch dispatch