Update mounted Windows state guidance

AGENTS.md

@@ -10,6 +10,10 @@ Guidance for coding agents working in this repo.
   upstream author/repo first, with `origin` pointing at upstream. If the user has
   an existing personal fork checkout, preserve it as a remote named `github`
   and set/add `origin` to the upstream repo instead of replacing local work.
+- Prefer repo-local state for planned installs unless the task explicitly
+  targets the user's live default state. For mounted Windows installs, prefer
+  the shared Windows-partition state directory configured in
+  `plugin-helper.local.toml` when both roots contain the same instance name.
 
 ## Workflow Rules
 

docs/DESIGN.md

@@ -94,11 +94,11 @@ For early development, a `--state-dir` option is useful so plans and manifests c
 When managing both local Linux and mounted Windows installs, install state must
 be separated by target root as well as by instance name. The current state
 layout is keyed by instance name, so two `1.44.1` installs should not share one
-state directory. A practical repo-local convention is:
+state directory. A practical convention is:
 
 ```text
 .state/                                                local Linux BSManager state
-.state-windows/  mounted Windows BSManager state
+~/Windows/Users/pleb/ops/plugin-helper/.state          mounted Windows BSManager state
 ```
 
 The registry and lockfile remain shared for a Beat Saber version. Downloads may

docs/notes/windows-compatibility.md

@@ -28,8 +28,7 @@ Windows instances.
   ```
 
 - Keep native Windows state local to that checkout, such as `.state/`, so it
-  does not mix with the Linux `.state` or mounted-Windows `.state-windows`
-  directories.
+  does not mix with Linux-managed state directories.
 
 ## Current Compatibility Notes