docs: fix MATH_MARCHING_CUBES §4 polarity + dims

Task 17 corrected the density sign convention in §1-§2 but left §4's worked
example on the old inverted convention, so the doc contradicted itself. §4 now
matches: negative is underground, positive is air. Also corrects a stale
16x16x64 chunk reference to 24x24x256.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Core/Scripts/MATH_MARCHING_CUBES.md

@@ -45,16 +45,17 @@ Instead of writing 256 `if/else` statements, the algorithm uses a hardcoded **Lo
 ### 4. Linear Interpolation (Why it looks Smooth)
 If the algorithm just drew triangles exactly halfway between the inside and outside corners, the terrain would still look a bit jagged (like a low-poly PS1 game). 
 
-To make it perfectly smooth, we **Interpolate**:
-* Corner A has a density of `1.0` (Very solid).
-* Corner B has a density of `-0.1` (Just barely in the air).
-* Because `-0.1` is much closer to our `0.0` Iso-Level than `1.0` is, the algorithm slides the triangle vertex much closer to Corner B. This creates gentle slopes and sharp cliffs dynamically.
+To make it perfectly smooth, we **Interpolate**. Remember the sign convention from §1 —
+negative is underground, positive is air:
+* Corner A has a density of `-1.0` (deep underground, very solid).
+* Corner B has a density of `0.1` (just barely up in the air).
+* Because `0.1` is much closer to our `0.0` Iso-Level than `-1.0` is, the algorithm slides the triangle vertex much closer to Corner B. This creates gentle slopes and sharp cliffs dynamically.
 
 ---
 
 ## ⚙️ The Execution Loop (What our C# Script will do)
 
-When the Server tells the Client to render a 16x16x64 chunk, the mesher does this:
+When the Server tells the Client to render a 24x24x256 chunk, the mesher does this:
 1. Loops through every X, Y, Z coordinate in the chunk.
 2. Checks the 8 corners of the current voxel.
 3. Creates an `8-bit integer` (a byte) based on which corners are solid (e.g., `00001111`).