Reimplement tick orchestration and document game-loop ownership

[Krarilotus]

TL;DR

Reimplements the game's tick coordinator with its original synchronization, pause and update order. Documents how it sits inside the outer loop, so we can understand the engine without treating every function call as a completed simulation step.

Adds GameStateStructures::processGameTick (0x0045CD10) through the existing subsystem resolvers, plus an ownership note complementing #202's WinMain reconstruction. The original save/sync early returns, wall-clock quit-vote command, separate clock and world gates, and maintenance while paused are preserved. Calendar updates retain the global receiver; the later statistics/economy calls retain this.

The ownership note also traces navigation maintenance into the lord update: its refresh countdown advances per call, even without a clock increment, and its rebuilt connectivity regions affect target/state decisions. It distinguishes outer work budgeting from command agreement and recovery; these are native dependencies, not claims that a community desync has been reproduced. It also follows worker movement recovery through disappearance, the population census, and the next peasant admission. These documentation follow-ups do not change the validated C++ implementation.

The instruction comparison caught signed comparisons of imported unsigned fields; explicit casts now preserve those native branches. No generated headers or resolver activation flags change. The soft status entry is 99.0%: the original supplies an unused ECX receiver before the empty Global::DoNothing, whereas its existing cdecl resolver has no receiver.

Validation:

• MSVC 2005 SP1 x86 RelWithDebInfo DLL built with this function selected locally.

• reccmp run against the original executable: raw similarity 35.98%, dominated by unresolved function/global resolver labels.

• Decoded instruction comparison resolves each of the 54 call/tail-call helpers to its original target and verifies the timeGetTime import. Branches, memory operands, call order and stack instructions match after accounting for the single unused ECX setup above (190 original instructions / 189 replacement instructions; 838 / 833 bytes). This is a structural comparison, not a claim of identical linked bytes.

• Existing review feedback followed: source/ownership documentation and soft status included; local comparison tooling remains outside the PR. This has not been installed into a live match.