docs(docs): replace Commonwealth with Settled Reach across docs

Updated in-universe "Commonwealth" references to "the Settled Reach"
in decisions, architecture docs, design docs, workshop outputs,
README, and wiki. Kept all references to Hamilton's books as
inspiration/comparison in historical discussions and wiki-review
workshop rounds.

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

docs/architecture/eval-godot-rust-bridge.md

@@ -9,7 +9,7 @@
 
 ## Executive Summary
 
-The Godot 4 (renderer/client) + Rust (simulation server) architecture is **viable and well-suited** to Commonwealth's confirmed requirements (D-010 client-server, D-010 deterministic simulation, D-017 observer queries). The path has real friction points but no hard blockers. The primary risk is not technical capability but **integration complexity** and **ecosystem maturity of gdext**.
+The Godot 4 (renderer/client) + Rust (simulation server) architecture is **viable and well-suited** to the Settled Reach's confirmed requirements (D-010 client-server, D-010 deterministic simulation, D-017 observer queries). The path has real friction points but no hard blockers. The primary risk is not technical capability but **integration complexity** and **ecosystem maturity of gdext**.
 
 | Area | Rating | Summary |
 |------|--------|---------|
@@ -73,7 +73,7 @@ The `godot-rust/gdext` crate provides Rust bindings for Godot 4's GDExtension AP
 - **CI integration:** Straightforward. `cargo build --release` then copy artifact to Godot project. Can be a single Makefile/justfile target.
 - **No Godot rebuild required.** Godot loads the extension dynamically. You just rebuild the Rust library and restart the Godot editor.
 
-### Verdict for Commonwealth
+### Verdict for the Settled Reach
 
 gdext is **the right choice for the Godot-Rust bridge** given that we want Godot as the renderer and Rust as the simulation. The pre-1.0 status is a real cost (budget 1-2 days per quarter for API migration) but not a blocker. The threading model fits our architecture perfectly. The FFI performance is adequate if we use packed arrays for bulk state transfer.
 
@@ -103,7 +103,7 @@ You do NOT get (and do not need): Bevy's renderer, window management, asset syst
 bevy_ecs = "0.15"  # or whatever current version is
 ```
 
-### Feature Assessment for Commonwealth
+### Feature Assessment for the Settled Reach
 
 | Feature | Status | Notes |
 |---------|--------|-------|
@@ -127,7 +127,7 @@ fn update_sound(query: Query<(&Position, &SoundEmitter)>, mut events: EventWrite
 
 `move_entities` and `decay_fog` access disjoint component sets, so the scheduler runs them in parallel automatically. `update_sound` reads `Position` (shared) so it can run in parallel with `decay_fog` but must wait for `move_entities` to finish writing `Position`. This is all automatic.
 
-For Commonwealth with potentially hundreds of NPCs, parallel perception queries, sound propagation, and AI decision-making, this is significant.
+For the Settled Reach with potentially hundreds of NPCs, parallel perception queries, sound propagation, and AI decision-making, this is significant.
 
 ### Determinism Concern
 
@@ -170,7 +170,7 @@ In case bevy_ecs proves problematic, here are the alternatives:
 
 **Recommendation:** `bevy_ecs` is the clear winner. If we need something lighter for prototyping, `hecs` is a good fallback (we'd write our own simple sequential scheduler, which is fine for v0.1 with 15 NPCs). Do NOT use specs or legion for new projects.
 
-### Verdict for Commonwealth
+### Verdict for the Settled Reach
 
 bevy_ecs standalone is an excellent fit. It gives us the ECS architecture, automatic parallelism, change detection for observer queries, and cache-friendly memory layout. The determinism requirement is achievable with explicit system ordering.
 
@@ -373,7 +373,7 @@ Based on community reports and technical blog posts:
 
 ---
 
-## 6. Recommendations for Commonwealth
+## 6. Recommendations for the Settled Reach
 
 ### Immediate Actions (v0.1 prototype)
 
@@ -476,6 +476,6 @@ Mapping back to confirmed decisions:
 
 ---
 
-*This evaluation recommends proceeding with the Godot 4 + Rust (gdext + bevy_ecs) architecture for the Commonwealth prototype. The architecture is sound, the tools are viable, and the risk profile is manageable. The primary investment is in defining clean abstractions early -- particularly the SimBridge trait and ObserverSnapshot format -- so that the inevitable gdext API churn and future multiplayer addition don't require rewrites.*
+*This evaluation recommends proceeding with the Godot 4 + Rust (gdext + bevy_ecs) architecture for the Settled Reach prototype. The architecture is sound, the tools are viable, and the risk profile is manageable. The primary investment is in defining clean abstractions early -- particularly the SimBridge trait and ObserverSnapshot format -- so that the inevitable gdext API churn and future multiplayer addition don't require rewrites.*
 
 *-- TYRE, Technical Architect*

docs/architecture/risk-godot-rust-bridge.md

@@ -53,7 +53,7 @@ GDExtension itself (Godot's native extension interface) has broken compatibility
 
 The Godot project has stated an intent to stabilize GDExtension ABI, but as of the last documented state, it has NOT been stabilized. Every Godot minor version bump is a potential "stop work and fix bindings" event.
 
-**Impact on this project:** The Commonwealth game will be in development for years. It will span multiple Godot versions. Each upgrade risks days to weeks of integration work, not on game features, but on making the bridge compile again.
+**Impact on this project:** The Settled Reach game will be in development for years. It will span multiple Godot versions. Each upgrade risks days to weeks of integration work, not on game features, but on making the bridge compile again.
 
 **Mitigation:**
 - Stay on one Godot version for as long as possible. Do not upgrade Godot unless a specific feature is needed.