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.

docs/currency-wars-route-factory.md

@@ -56,8 +56,12 @@ The reference `gfRouteCreateNode` uses a run-specific neutral camp for Monster
 nodes. `gfRoutePlanForRun` reads that camp from an internal FFGO run field; it
 is not represented by the saved Client stage's boss camp list. The captured
 first battle's monster IDs match more than one native season camp, so they do
-not uniquely recover the saved run's neutral camp. The reference uses one wave
-of three monsters for the first Monster node and five thereafter, filtering by
-the captured maximum tier; determining the run camp is still required before
-constructing that layer. EliteBranch generation additionally needs its option,
-difficulty and reward contract. No player save was modified by this audit.
+not uniquely recover the saved run's neutral camp. As an explicit compatibility
+policy, the new Monster factory picks an eligible, random-enabled captured
+season camp deterministically from the run ID. This retains one camp for the
+same run but does not claim to recover the reference's original choice. The
+reference wave counts, tier limit and chapter star weights come from the
+revision-bound resource. A focused unit test checks stable camp selection and
+valid monster membership; the generated node is not yet verified in Client.
+EliteBranch generation additionally needs its option, difficulty and reward
+contract. No player save was modified by this implementation.

docs/cw-route-continuation-audit.md

@@ -11,11 +11,14 @@ These names are joined from `CurrencyWarsCatalog.json` stage routes and
 `CurrencyWarsReferenceNodes.json` templates. They describe the template, not
 necessarily a run's dynamically substituted node display.
 
-`cwAdvanceRouteNode` currently calls `cwGenerateReferenceEnemyLayer` for every
-destination. That factory accepts only Boss and CampMonster; it rejects Supply,
-EliteBranch, and Monster. `cwSelectSupply` also requires an exact captured
-transition. Consequently a successful 2-1 battle does not establish that 2-2
-or later rooms can be played. Constructing the remaining node layers, pending
+`cwAdvanceRouteNode` now creates a captured empty Supply container and uses
+`cwGenerateReferenceEnemyLayer` for other destinations. The enemy factory
+accepts Boss, CampMonster and Monster; it still rejects EliteBranch. The
+Monster factory uses the explicit replacement-camp policy documented in
+`currency-wars-route-factory.md` because the old run's neutral camp is not
+present in its saved protocol data.
+Consequently a successful 2-1 battle does not establish that 2-2 or later
+rooms can be played. Constructing the remaining node layers, pending
 actions and rewards needs their corresponding native/reference rules and a
 current-Client check; copying the first Supply's randomized inventory would not
 prove the later rooms correct.
@@ -23,10 +26,56 @@ prove the later rooms correct.
 `cwCapturedSupplyLayer` derives the empty Supply node container from the
 revision-bound transition capture and validates that it has no camp or enemy
 branches. It neither copies the captured option list nor modifies a run. It is
-not yet connected to route advancement: FFGO's `gfPendingSupplyOf` and
-`gfPendingFillSupplyOptions` also choose a chapter/state-dependent offer,
-including distinct roles and random equipment. That pending offer remains
-unmapped; advancing without it would strand the player in Supply.
+now connected to route advancement. The generated RoundBegin path creates a
+Supply offer from captured role variants and equipment. SupplyBox is not
+implemented. Automated offer
+generation checks pass; the new route is not yet verified in the Client.
+
+## Updated FFGO Supply evidence
+
+The user-supplied reference binary has SHA-256
+`00a75ef82614977d951250705250c6ad478ef7cdde717c761f0c70244a84ed10`.
+Its `gfPendingSupplyOf` reads the run rules `SupplyRarity`, `SupplyStar`,
+`SupplyEmblems`, and `SupplyBox`. `gfPendingFillSupplyOptions` reads
+`GridFight_BaseSupplyRoleNum`, draws roles and selects equipment from `Basic`,
+`Craftable`, or `Emblem`, depending on the chapter and rules. These names were
+resolved from the reference binary, not inferred from the earlier dump.
+`gfFxHProjectRunState` also projects `ExtraSupplyOption` into the additional
+option count consumed by `gfPendingFillSupplyOptions`; the generated offer
+uses the saved run rule and checks the combined count before drawing.
+
+The updated reference also calls `gfPendingApplySupplyEquipChance`, which
+reads `SupplyEquipChance`, `SupplyEquip`, and `SupplyEquipChapter`. When the
+conditions match, it can replace equipment in one randomly selected option.
+The generated offer uses saved run rules and validates replacement items
+against captured equipment. Pool accounting and all run modifiers need more
+comparison; later node families still need implementation and Client checks.
+
+When a Supply selection has no captured next-node transition,
+`cwSelectSupply` now delegates to the generated route factory on the same
+detached transaction and preserves finish/unlock/level/pending notification
+order. The existing captured path remains unchanged. This removes the separate
+capture-only restriction after a generated Supply choice, but the factory
+still rejects unsupported destination families, including the EliteBranch
+following 2-2; the selection remains uncommitted until that family is
+implemented. No Client run has exercised this fallback.
+
+For a selected Encounter branch, the battle settlement now grants supported
+gold, EXP, or item rewards when the reported progress reaches the branch's
+threshold, using the selected server-side drop list on the detached snapshot.
+Unmapped reward types fail without committing. Perfect-clear monster Orb
+generation is not implemented; Client verification is still outstanding.
+
+The native captured Encounter at route 2801 chapter 1 section 4 contains two
+branch displays, each with its own penalty, monster wave and `BOAMLLHPNEC`
+drop. A read-only check of the saved run at chapter 2 section 1 generated its
+next Supply node and four choices on a detached copy; the saved run was not
+written and no Client interaction was performed. The latest FFGO's
+`gfRouteFillEliteBranch` constructs branch IDs from the node template's first
+parameter and option kind, resolves difficulty through
+`gfRouteEliteBranchDifficulty`, and builds the reward in
+`gfRouteEliteOptionReward`. These are useful evidence, but matching the later
+branches to this Client's option, penalty and difficulty data remains open.
 
 After the final node, `cwAdvanceRouteNode` returns `CW route has no next node`.
 At zero HP, `finishCurrencyWarsBattle` returns `CW defeat settlement requires