Fix GUI weather: valid IDs, defer & reset

Replace invalid Fallout 4 weather form IDs with valid ones (including fixing Clear from 0002852a -> 0002b52a) and update protocol examples and server presets accordingly. Change the plugin to re-queue/defer server weather payloads when the local assigned player ID is not yet available (so early GUI clicks are not dropped) and add a log entry when deferring. Reset player/host assignment on server startup (_next_player_id = 1 and clear _world_state_host_player_id) to avoid stale host IDs after restarts. Also update changelog and developer log entries describing the fixes and recommended manual testing steps.

docs/dev-log.md

@@ -9,6 +9,92 @@ failed experiments, successful tests, and next steps.
 
 ---
 
+## 2026-06-24 - Replace Invalid GUI Weather IDs
+
+### Summary
+Fixed GUI weather presets that were using invalid weather IDs (`00148c..`), which caused Fallout 4 to report `Invalid weather '<id>' for parameter Weather ID.` when running `fw`.
+
+### Files Changed
+- `server/world_state_presets.py`
+- `protocol/server-world-state.md`
+- `changelog.md`
+
+### Details
+- Updated default GUI weather presets to valid Fallout 4 weather form IDs:
+  - Clear: `0002b52a` (corrected from typo `0002852a`)
+  - Cloudy: `001cc186`
+  - Overcast: `001c8556`
+  - Fog: `001c3473`
+  - Rain: `001ca7e4`
+  - Radstorm: `001c3d5e`
+  - Glowing Sea: `000f1033`
+- Updated protocol examples/documentation to match these IDs.
+
+### Testing
+- Not re-tested in-game in this session.
+- User-provided screenshot confirms previous IDs failed with `Invalid weather` in console.
+- Recommended: run `fw <each preset id>` manually once, then verify GUI buttons trigger the same IDs.
+
+### Known Issues
+- Weather IDs can differ with unusual load-order/mod setups; override presets in `server/world_state_presets.py` if needed.
+
+### Next Steps
+- Restart server GUI so it loads updated presets, then test one-click weather changes outdoors.
+
+---
+
+## 2026-06-24 - Reset Player IDs on Server Restart
+
+### Summary
+Fixed a restart regression where GUI weather could silently do nothing after server restarts because player IDs and world-state host assignment were not reset between runs.
+
+### Files Changed
+- `server/server_core.py`
+- `changelog.md`
+
+### Details
+- Server startup now resets `_next_player_id` to `1`.
+- Server startup now clears `_world_state_host_player_id` so the first newly connected client becomes the host for that run.
+- This keeps the plugin's weather gate (`playerId == 1`) aligned after restart.
+
+### Testing
+- Not re-tested in-game in this session.
+- Recommended: start server, connect client, set weather; stop server; start again; reconnect same client and set weather again.
+
+### Known Issues
+- None currently known.
+
+### Next Steps
+- Rebuild/reload as needed, then verify `CommonwealthOnline.log` shows weather command execution after both first start and restart.
+
+---
+
+## 2026-06-24 - Defer Weather Until Player Assignment
+
+### Summary
+Fixed intermittent GUI weather clicks by deferring weather apply when `serverWorldState` arrives before local player assignment is complete.
+
+### Files Changed
+- `plugin/src/F4TWorldStateSync.cpp`
+- `changelog.md`
+
+### Details
+- If a weather request arrives before `GetAssignedPlayerId()` is available, the plugin now re-queues that server world-state payload instead of discarding it.
+- Once assignment completes, player 1 applies the queued weather command normally.
+- Non-player-1 clients still ignore weather commands as intended.
+
+### Testing
+- Not re-tested in-game in this session.
+- Recommended: connect client, immediately click weather once in GUI, confirm the first click now applies without repeated clicks.
+
+### Known Issues
+- None currently known.
+
+### Next Steps
+- Verify in logs that early weather packets show a one-time "deferred" message followed by weather command execution after assignment.
+
+---
+
 ## 2026-06-23 - GUI Weather Uses Numeric `fw` ID
 
 ### Summary