feat: port VerticalShafts — three ops reused from Maze unchanged

The port that tests the thesis rather than the fidelity. Previous ports asked whether
the decomposition reproduces the original; this one asks whether operators actually
get reused across archetypes, which is section 2.5's claim and the only reason to do
this refactor instead of tidying the switch.

ConstantRock, SdfRoughness and SdfCarve are Maze's, reused without a line changed.
In the switch, GetMazeDensity and GetVerticalShaftDensity are two ~100-line functions
with nothing visibly in common; as operators they are the same three ops with a
different source and different tuning (freq 0.1 vs 0.12, window rough+4 vs R+rough+2).

New: FShaftFieldSource (infinite cylinders + hash-gated connectors into the SDF
channel) and FShaftLedgeMod (banded shelves on the +X/+Y half so the shaft stays
climbable).

Deviation from section 6, stated: it suggested splitting the source so the XY-pure
cylinder half could get an exact box verdict. Kept as one op because the connectors
derive from the same 3x3 roll and the ledge mod needs the shaft list anyway, so
splitting means rolling twice or sharing a cache between two ops. Forfeited: the exact
verdict on the cylinder half. Kept: a conservative EffectOverBox testing circles and
connector reach.

FShaftLedgeMod gates on the POST-roughness Sdf as the stack left it; re-deriving it
would use the pre-roughness value and shift every ledge. Reading the channel rather
than recomputing is what the two-channel sample is for.

Compile fix: FCells was declared below the functions returning it. Member bodies are
deferred, return types are not.

Ported: Maze, FlatPlain, CrystalChamber, SurfaceWorld (biomes included),
VerticalShafts — 5 of 8.

UNVERIFIED: not compiled past the FCells fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Source/VoxelForge/Public/VoxelDensityOpStack.h

@@ -230,6 +230,19 @@ namespace VoxelDensityOps
                                        int32 Seed, float SpineRadius,
                                        const UVoxelStrateManager* StrateManager);
 
+    /**
+     * VerticalShafts — 8 ops, et **TROIS viennent de Maze sans une ligne de changement** :
+     *   ConstantRock → ShaftField → SdfRoughness → SdfCarve → ShaftLedge → [structural post ×3]
+     *
+     * C'est la démonstration que `§2.5` promettait : dans le `switch`, Maze et VerticalShafts sont
+     * deux fonctions de ~100 lignes sans rien de commun à l'œil ; en opérateurs, ce sont les mêmes
+     * trois ops avec une source différente et d'autres réglages (fréquence 0.1 au lieu de 0.12,
+     * fenêtre `rough + 4` au lieu de `R + rough + 2`).
+     */
+    VOXELFORGE_API void BuildVerticalShaftStack(FVoxelOpStack& OutStack, const FVerticalShaftParams& P,
+                                                int32 Seed, float SpineRadius,
+                                                const UVoxelStrateManager* StrateManager);
+
     /**
      * La pile Maze complète, décomposée — PAS un `FMazeOp` monolithique :
      *   ConstantRockSource → LatticeCorridorSource → SdfRoughnessMod → SdfCarve → [structural post]