Refactor Units.php & Battle.php & Technology.php

[Shadowss]

We must to review and refactor units, technology and battle php files.
It is important to review calculateBattle in Battle.php and simulate in same file. And in Units and Technology we must to full refactor

[Ferywir]

Thanks for the assignment! Here is a proposed roadmap for #219, following the
same incremental, behaviour-preserving approach that worked well for #155
(one cohesive extraction per PR, validated before merge).

Note: I'd suggest we finish #155 first and start #219 only once
sendunitsComplete() is fully decomposed, to avoid two large refactors moving
on the combat code at the same time.

Guiding principles

• Behaviour-preserving: each PR is a pure refactor, no logic change.
• One method / one cohesive change per PR, ordered by increasing risk.
• Garde-fou: every combat-affecting change is validated with a deterministic
  A/B battle harness (baseline vs refactor → identical output) before merge,
  plus an in-game test before anything lands.
• Note: calculateBattle() is shared by both the real combat resolver
  (sendunitsComplete) and the simulator (Battle::simulate), so I want a
  safety net covering both paths first.

Phase 0 — Safety net (prerequisite)

• Extend the A/B harness with a deterministic scenario that includes
  catapults + rams + wall (no chiefs ⇒ no rand()), to cover the building-
  damage sections, plus a frozen simulator scenario (procSim/simulate).

Phase 1 — Units.php & Technology.php (no rand(), no combat math — lowest risk)

1. Technology: merge upgradeSword() + upgradeArmour() →
   upgradeWeaponOrArmour($get, $type) (there's already a //TODO: Merge).
2. Units: collapse the duplicated procUnits() cases 1–4.
3. Units: extract buildHeroStats() (the two branches of Hero() are
   near-identical).
4. Units: split checkErrors() →
   parseCoordinates() / resolveTarget() / validateTroopSelection() /
   validateTargetPlayer().
5. Units: split sendTroops() → resolveCatapultTargets() (+ rally-point rules).
6. Technology: make getTrainingList() table-driven.
7. Technology: split trainUnit() → getTrainingTime() /
   checkTrainingBuilding() / getMaxTrainable().
8. Technology: tidy getUpkeep() + de-duplicate getUnits()/getAllUnits().

Phase 2 — Decompose calculateBattle() (one private helper per section)

9. computeBounty() — bounty (pure)
10. computeCasualties() — attacker casualties (pure)
11. applyWallAndResidence() — wall + residence (pure)
12. computeTotalPoints() — rap/rdp (pure)
13. computeMorale() + computeMfactor() — morale (pure)
14. computeAttackerForces() — ap/cap/catp/ram + hero offense (pure)
15. computeDefenderForces() — base defence + reinforcements (reads DB, no writes)
16. computeLossRatios() — type 1/3/4 loss ratios (isolates the only rand())
17. applyCatapultDamage() / applyRamDamage() — building/wall damage (deterministic)
18. applyHeroBattleDamage() — hero damage (unifies the 3 duplicated DB blocks) — last, since it wr

Phase 3 — simulate() / procSim()

Clean up input parsing once the simulator is covered by the harness.

Open question

Do you want these classes migrated to src/ under the App\ namespace as part
of this, or kept in GameEngine/ for now to keep the diffs minimal? I'd lean
towards keeping them in place until the decomposition is stable.

[Shadowss]

Yeah great timeline. I'll try to keep it in GameEngine until decomposition is stable. Fist of all we must finish sendunitsComplete