Make settlement destination claims atomic

[fabianwgl]

What changed

• lock the settling account and destination map rows before checking culture points or creating a village
• require a free, buildable wdata tile with a matching free available_villages row and no existing vdata row
• return settlers and founding resources when a stale or competing destination loses the claim
• treat an unexpected village-creation failure as a retryable scheduled-task failure
• add fresh-process regression coverage for stale availability state and two simultaneous settlement movements targeting one tile

Why

Settlement resolution previously checked only wdata.occupied and then performed separate, unlocked reads. A stale availability row or two workers targeting the same tile could consume a movement without safely creating exactly one village, losing settlers or producing duplicate player-facing effects.

Impact

Valid settlement, including grey-area settlement and its Natar response, keeps the existing behavior. Invalid or concurrently claimed targets now resolve deterministically and conserve the losing settlers/resources.

Verification

• ./scripts/verify.sh
• two-process settlement race in tests/runtime-regression.php
• PHP syntax and PHPStan checks
• formula golden regressions
• complete-round regression
• independent diff review