ENH: Add Sharp Bounding Box Edges option to M3C surface meshing

[imikejackson]

Summary

M3C places every vertex on a cell edge, face center, or body center, so the marching squares that straddle a bounding box edge (one real corner, three ghost corners) join their edge midpoints with a diagonal. Every box edge and corner therefore came out with a 45 degree chamfer half a cell deep on each wall, which downstream FEA mesh preparation (Gmsh) cannot use without hand repair. Development builds of the port produced sharp edges; the chamfer appeared in the released version.

• Add a Sharp Bounding Box Edges BoolParameter (default on) to M3CSurfaceMeshingFilter and bump the parameters version to 3. Older pipelines take the default.
• Add a post-pass in finalizeMesh that snaps the outermost row of wall nodes onto the neighbouring wall plane, merges the nodes that coincide on the box edge lines and corners, and drops the collapsed chamfer triangles. The pass works on the integer half-cell node lattice, so it is exact for any spacing and origin. One-cell-thick axes are left chamfered since the single wall row is half a cell from both bounding planes.
• Document the option with before/after screenshots and update M3C_Demo.d3dpipeline.
• Second commit: issue M3CSurfaceMeshing emits orphan vertices that no triangle references #1706 (orphan vertices) turned out to be already fixed by the single ghost sentinel from BUG: Keep the M3C surface mesh inside the input volume #1718. Re-measured across the cylinder, all-background, polycrystal, porosity, toy, and Small IN100 datasets in both Bounding Box Skin modes: zero orphan vertices everywhere. CheckMeshIntegrity now requires every emitted vertex to be referenced by a triangle, the all-background skin test requires zero vertices, and the orphan notes are removed from the docs and comments.

Closes #1706

Test Plan

• New tests: exterior triangles coplanar with a single wall, all eight box corners present, no coincident vertices, single-feature box watertight, one-cell-thick volume well formed, Small IN100 sharp edges
• All 29 M3CSurfaceMeshing and Bounding Box Skin tests pass
• Sphinx doc build clean for the M3C page
• clang-format 19.1.1 verified on touched files
• Out-of-core build not run locally

[nyoungbq]

I don't know how many of the triangles are actually touched in practice so this unordered_set may be more efficient, but a std::vector of bool is bit packed whereas the unordered set of SiteId which is probably uint64_t meaning you would have to be hitting fewer than 1 in 64 to make this more space efficient (which is not impossible if your only touching corners or smtg). You know the algorithm better just thought I would point it out.

[imikejackson]

Good point. Let me run a memory analysis. Also, std::vector is only bit packed on Windows I think? Maybe I am remembering that incorrectly.

[imikejackson]

I measured this against the candidate-space and edge-space bounds. I was remembering std::vector<bool> incorrectly: libc++, libstdc++, and MSVC all use packed-bit representations.

The important distinction here is scaling. A dense mask needs 7 * (x + 2) * (y + 2) * (z + 2) bits, while touched is limited to nodes along the box edges and grows roughly as O(x + y + z). Using the geometric upper bound for touched, the allocations on the current macOS/libc++ build were:

• 4 x 3 x 5: vector<bool> 184 B; unordered_set 4,072 B
• Small IN100 (51 x 26 x 51): vector<bool> 68,824 B; unordered_set 37,544 B
• 100 cubed: vector<bool> 928,560 B; unordered_set 83,416 B

The tiny test volume favors the bit vector, but realistic volumes increasingly favor the sparse set. The set also fits the final pass: erase every surviving node ID, then iterate only the remaining orphans. A dense mask would require scanning every candidate ID or maintaining a second sparse list.

I am going to retain the unordered_set. If this becomes a measurable hot spot, the next representation I would compare is a sorted sparse vector<SiteId> plus a touched-sized flag vector.