docs(simulation): correct stale cascade docs and pin layer order (#955)

Address the doc/test-correctness items from PR #149 review:

- cascade.rs: Layer 3 is RNG-free (pure fn of attractors+cities); it does
  not consume the carried SeedChain. Corrected the "first RNG-using layer"
  claims on the module doc and the Settlement variant (Hoshe H3).
- cascade.rs: layers_are_ordered now also asserts Topography < Settlement,
  pinning the invariant the up_to >= Settlement guards rely on (Tyre T2).
- features.rs: strength is an integer 0-100 (quantized at extraction), not
  f32, and consumers that rank by it use the integer value (Hoshe H2).
- layer_proxy.rs: AtlasLayerRequest.up_to is not yet honored — run_work_item
  runs through Settlement unconditionally; per-request depth deferred to
  #1021 (Tyre T1).

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

server/src/atlas/features.rs

@@ -2,8 +2,10 @@
 //!
 //! After D8 drainage analysis (D-208), this module extracts the 7
 //! `AttractorType` tags from the heightmap + river network. Each attractor has
-//! a pixel position and a normalized `strength` (0.0–1.0) derived from local
-//! terrain quality.
+//! a pixel position and a `strength` (integer 0–100) derived from local terrain
+//! quality — computed in floating point, then quantized to an integer at the
+//! extraction boundary so all downstream decisions stay integer-deterministic
+//! (D-010).
 //!
 //! **D-209 / D-223 reconciliation:** D-209 reads ocean/lake polygons from
 //! `markers.json`, but D-223 reduced markers to a names-only pool — those
@@ -13,8 +15,10 @@
 //!
 //! **Determinism (D-010 #4):** all collections iterate in sorted/row-major
 //! order; the final attractor list is sorted by `(attractor_type, row, col)`.
-//! No `HashMap`/`HashSet` iteration. `strength` is f32 but is never used as a
-//! sort key.
+//! No `HashMap`/`HashSet` iteration. `strength` (integer 0–100) is not part of
+//! that ordering here, so float quantization can't perturb the sort; consumers
+//! that rank by strength (e.g. `layer1::attach_feature_names`) do so on the
+//! integer value.
 
 use std::collections::{BTreeMap, VecDeque};