Update AA synchronization, CW progression and diagnostics

docs/aa-round-sync.md

@@ -11,7 +11,7 @@ The protocol's `ChallengePeakGroupDataUpdateScNotify` contains one `ChallengePea
 ## Source changes
 
 - `internal/gameserver/aa_round_sync.go` builds a resource-validated desired group and selected-group/version digest. The default comes from the same loaded Peak groups as the data handler. It reads selection without writing saves.
-- `aa_round_sync.lua` uses the actual current Client's `ChallengePeakModule.SendGetChallengePeakDataRequest()` and observes `CurrentPeakGroupID`. It sends one outstanding request and waits for the native value to match. It does not fabricate a response, alter private state, close a page, change scene, start a Battle, or remap a PeakID.
+- `aa_round_sync.lua` uses the actual current Client's `ChallengePeakModule.SendModuleInitRequest()` and observes `CurrentPeakGroupID`. It resolves the exact zero-argument method through reflection because the xLua bridge does not consistently expose native methods as Lua functions. It sends one outstanding request and waits for the native value to match. It does not fabricate a response, alter private state, close a page, change scene, start a Battle, or remap a PeakID.
 - Server gating defers while `CURRENT_BATTLE`, `ChallengeRun`, or CW is active; the Client also checks `BattleGamePhase`. Existing native login initialization (`CurrentPeakGroupID == 0`) is allowed to finish without issuing a duplicate request.
 - `GetChallengePeakData` retains the existing Peak run's group until that run is left. It logs the actual selected group, number of groups and active-run state. Missing Peak resources now produce a typed error rather than a fabricated group/room list.
 - Server README and Thai/English Srtool copy describe deferred native refresh rather than claiming that reopening the page necessarily causes a data request.
@@ -25,8 +25,24 @@ UInt32 get_CurrentPeakGroupID()
 Void SendGetChallengePeakDataRequest()
 ```
 
-This evidence establishes the named native API, not its successful execution or UI refresh. Runtime pointers in the log are process-local and are not shipped or reused.
+The earlier metadata evidence established method names only. Runtime pointers in the log are process-local and are not shipped or reused.
 
-`go build ./internal/gameserver` and `node --check ../GaC-srtool/js/i18n.js` passed. No tests, save mutations, executable replacement, restart or Lua staging were performed for this source change. Root must wire `loadAARoundRefreshLua(s)` into heartbeat, build/deploy, and confirm the real request/reply plus `[GAC_AA_ROUND_SYNC] applied` and the displayed round before reporting Client success.
+### Runtime correction and deployment — 2026-10-30
+
+Bounded disassembly of the live module's method pointers proved that the misleadingly named `SendGetChallengePeakDataRequest` sends `GetCurChallengePeakCsReq` (8945), which only refreshes the current run. `SendModuleInitRequest` sends `GetChallengePeakDataCsReq` (8942), the full round catalog. Names and IDs are verified against `protocol/proto/cmdid.go`; no aliases were added. Evidence is in `.runtime/aa-send-request.asm`, `aa-agent-send.asm`, `aa-init-request.asm`, and `aa-agent-init.asm`. Examined GameAssembly SHA256: `4aa08a0706f27d2cf9951b61920c179140ece9ea94f7e34422c18e46922939b6`.
+
+After selecting group 3 through the existing SDK endpoint, real Client/server logs showed:
+
+```
+[GAC_AA_ROUND_SYNC] requested group=3 previous=1
+PEAK_DATA current_group=3 groups=11 active_run=false
+[GAC_AA_ROUND_SYNC] applied group=3
+```
+
+This confirms the native module accepted the selected group. After deployment the user confirmed that the AA round changed from Srtool and a room could be entered.
+
+Separately, one malformed reference scene key (`6` in group 5) caused strict override validation to reject all AA scenes, including other rounds. It is corrected to stage 501 using the unique missing `PreLevelIDList` entry and matching `NpcMonsterIDList` actor from Client resources; coordinates, actor, entrance and maze group are unchanged. Provenance is stored in `ChallengePeakSceneOverrides.json`. The imported `peak.stages` section is now decoded correctly rather than interpreting the names `stages`/`groups` as fake stage IDs.
+
+`TestPeakSceneCatalogMatchesClientGroups`, Peak config/limit tests and the Game server build passed. All 44 resource stage placements validate. The new executable was installed and the Game server restarted; temporary probes were removed from `scripts/`. These checks do not prove battle/scene success in the Client.
 
 There is intentionally no timeout retry while an in-flight request cannot be distinguished from an unchanged result. A changed native group proves completion; new desired choices can then be requested. Reconnect/module replacement resets local request tracking. All activity schedules and resource room/boss definitions remain intact.