docs(@projects/@magic-civilization): 📝 p3-18 — correct P5/P6 blocker: gdext builds locally (crate is magic-civ-physics-gdext)

The earlier "cargo resolver panic blocks the gdext dylib" claim was wrong: I was
running `cargo -p gdextension-api`, which is a crates.io godot dependency, not our
crate. The local crate is `magic-civ-physics-gdext`; `cargo check -p
magic-civ-physics-gdext` is green in ~38s. P5 (UI embark) and P6 (demo) are
feasible locally via build-gdext.sh + GUT — not build-host-gated.

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

.project/objectives/p3-18-water-crossing-embark-transport.md

@@ -102,8 +102,10 @@ two-tier Civ model on the existing tree (`public/resources/techs/naval.json`):
   `pathfinder.gd::_is_passable`/`find_path`/`find_path_with_fog` + their callers,
   or (Rail-1 preferred) route world_map movement through the Rust pathfinder. Also
   drop the vestigial embark inputs from `legal_actions_for`/`can_invoke` + GDScript
-  callers. *(Needs the build host: the bridge must expose `embark_level` to
-  GDScript + GUT/dylib verify; local cargo resolver panics on gdextension-api.)*
+  callers. *(Feasible locally — the gdext crate is `magic-civ-physics-gdext` and
+  `cargo check -p magic-civ-physics-gdext` is green in ~38s; the earlier "cargo
+  resolver panic" was a wrong `-p gdextension-api` (that name is a crates.io godot
+  dep, not our crate). Build the dylib via `build-gdext.sh`; GUT verifies.)*
 - [ ] **P6 — end-to-end.** A headless 1v1 (both sides driven) reaches a decisive
   `game_over` by crossing water to capture the enemy capital — the demo that
   motivated this objective.