refactor(rust): collapse save layer and trim unused APIs

AGENTS.md

@@ -1,7 +1,7 @@
 # Repository Guidelines
 
 ## Project Structure & Module Organization
-`rust/` contains the Godot GDExtension crate. Core gameplay state lives in `rust/src/core`, runtime orchestration in `rust/src/game`, player behavior in `rust/src/player`, entities in `rust/src/entity`, room loading in `rust/src/rooms`, save logic in `rust/src/save`, and Rust-backed UI in `rust/src/ui`.
+`rust/` contains the Godot GDExtension crate. Core gameplay state lives in `rust/src/core`, runtime orchestration in `rust/src/game`, player behavior in `rust/src/player`, entities in `rust/src/entity`, room loading in `rust/src/rooms`, and Rust-backed UI in `rust/src/ui`.
 
 `godot/` is the Godot 4 project. Scene files live under folders such as `godot/entity/`, `godot/player/`, and `godot/ui/`. Content pipelines are under `godot/pipeline/ldtk` and `godot/pipeline/aseprite`. Third-party add-ons are vendored in `godot/addons/`.
 

ARCHITECTURE.md

@@ -10,13 +10,12 @@ At runtime, Godot instantiates Rust `GodotClass` nodes from scene files such as
 
 ### `rust/`
 
-- `src/core` — Pure gameplay/session/progress logic. Key files: `player.rs`, `world.rs`, `session.rs`, `progress.rs`. Relationships: consumed by `game`, `player`, `entity`, and `save`; it defines movement rules, room-transition planning, spawn resolution, and the in-memory progress repository.
-- `src/game` — Top-level gameplay orchestration and room lifecycle. Key files: `mod.rs` (`Game`), `room_manager.rs` (`GameRoomManager`), `room_runtime.rs`, `portal_connector.rs`, `player_spawner.rs`. Relationships: depends on `core`, `rooms`, `player`, `entity`, and `save`; it is the owner of the live player/room session.
+- `src/core` — Pure gameplay/session/progress logic. Key files: `player.rs`, `world.rs`, `session.rs`, `progress.rs`. Relationships: consumed by `game`, `player`, `entity`, and `ui`; it defines movement rules, room-transition planning, spawn resolution, and the in-memory progress store.
+- `src/game` — Top-level gameplay orchestration and room lifecycle. Key files: `mod.rs` (`Game`), `room_manager.rs` (`GameRoomManager`), `room_runtime.rs`. Relationships: depends on `core`, `rooms`, `player`, and `entity`; it is the owner of the live player/room session.
 - `src/player` — The player-facing Godot class and adapters around core movement. Key files: `mod.rs` (`Player`), `input_adapter.rs`, `animation.rs`, `platform.rs`, `push.rs`, `hazard.rs`. Relationships: wraps `core::player::PlayerMovement` with Godot physics, animation, and collision handling; instantiated by `player/player.tscn`.
 - `src/entity` — Rust implementations of room entities. Key files: `checkpoint.rs`, `collectible_star.rs`, `plain_key.rs`, `plain_lock.rs`, `portal.rs`, `pressure_plate.rs`, `switch_door.rs`, `moving_platform.rs`, `crumbling_platform.rs`, `pushable_crate.rs`, `persistence.rs`. Relationships: mostly leaf behaviors instantiated inside imported room scenes; persistent entities flow through `core::progress` via `entity::persistence`; `game` reaches in mainly for portal signal hookup.
 - `src/rooms` — Room-scene loading and caching. Key files: `loader.rs` (`RoomLoader`). Relationships: used by `game::room_runtime`; depends only on Godot resource loading and the room naming convention.
-- `src/save` — Thin facade over progress state. Key files: `mod.rs`, `SaveApi`. Relationships: re-exports and wraps `core::progress` for Rust UI and any Godot-facing callers; used by `game` and `ui`.
-- `src/ui` — Rust-backed menus and HUD/map widgets. Key files: `main_menu.rs`, `pause_menu.rs`, `star_counter.rs`, `world_map.rs`, `world_map_model.rs`. Relationships: depends on `save`, and `world_map.rs` also reads `GameRoomManager` to highlight the current room.
+- `src/ui` — Rust-backed menus and HUD/map widgets. Key files: `main_menu.rs`, `pause_menu.rs`, `star_counter.rs`, `world_map.rs`, `world_map_model.rs`. Relationships: depends on `core::progress`, and `world_map.rs` also reads `GameRoomManager` to highlight the current room.
 
 ### `godot/`
 
@@ -35,14 +34,14 @@ At runtime, Godot instantiates Rust `GodotClass` nodes from scene files such as
 - `rust/src/core` is the decision-making layer for movement, room/session planning, and progress tracking. Higher layers may depend on it; it does not depend on `game`, `player`, `entity`, or `ui`.
 - `GameRoomManager` owns the active gameplay session. Room loads/unloads, boundary transitions, portal teleports, player spawning, and death reload/restart decisions all funnel through it.
 - Room traversal is coordinate-based, not graph-authored in code. Adjacent room transitions come from `BoundaryDetector` plus room existence checks; portals are the explicit non-adjacent transition path.
-- Imported rooms must keep the `Room_<x>_<y>.scn` naming scheme and an `Entities` layer. `RoomLoader`, `GameRoomManager`, and `portal_connector` assume that structure.
-- Persistent world state goes through `core::progress`, usually via `entity::persistence`, with LDtk IID metadata preferred over position-based fallback keys. Individual entities do not maintain their own save stores.
+- Imported rooms must keep the `Room_<x>_<y>.scn` naming scheme and an `Entities` layer. `RoomLoader` and `GameRoomManager` assume that structure.
+- Persistent world state goes through `core::progress`, usually via `entity::persistence`, with LDtk IID metadata preferred over position-based fallback keys. Individual entities do not maintain their own stores.
 - Scene files are mostly composition and data. Runtime gameplay logic for player, rooms, menus, HUD, and entities lives in Rust `GodotClass` implementations; GDScript is mainly reserved for import/editor tooling.
 - `rooms::RoomLoader` only knows how to load and cache scenes. It intentionally does not know about save state, player setup, or transition policy.
 
 ## Cross-Cutting Concerns
 
 - Persistence is currently process-local. `core::progress` stores checkpoints, collected entities, star count, and explored rooms in a thread-local repository so state survives scene changes and menu transitions, but there is no on-disk save/load layer yet.
 - Content generation is a first-class part of the architecture. LDtk post-import scripts assign exported fields and metadata that runtime Rust code depends on, especially for room coordinates, portal destinations, pressure-plate targets, and persistent entity IDs.
-- Runtime communication leans on Godot signals at module seams: menu buttons change scenes, portals request teleports, the player emits `death_finished`, and entities emit state-change signals while delegating shared state to `save`/`progress`.
-- Testing is mostly inline Rust unit tests. The repo favors keeping deterministic logic in `core`, `save`, `rooms`, and small helper modules so it can be tested without a live Godot runtime.
+- Runtime communication leans on Godot signals at module seams: menu buttons change scenes, portals request teleports, the player emits `death_finished`, and entities emit state-change signals while delegating shared state to `core::progress`.
+- Testing is mostly inline Rust unit tests. The repo favors keeping deterministic logic in `core`, `rooms`, and small helper modules so it can be tested without a live Godot runtime.