Account for static blockers in frontier reachability

[DevOpsOfChaos]

Summary

• account for blocking static map objects in frontier-distance reachability checks
• keep terrain-based reachability behavior otherwise unchanged
• add regression coverage for static blockers in the frontier-distance path check

Motivation

The FRONTIER_DISTANCE_REACHABLE addon previously checked terrain reachability only. This meant blocking static map objects, such as decorative objects used as permanent path blockers, could be ignored when determining whether enemy military buildings were reachable.

This keeps the check intentionally narrow: it only treats blocking Staticobjects as blockers and does not switch to full human pathing behavior.

Validation

• Built Test_integration locally with Visual Studio 2022 / Debug
• Ran Test_integration.exe --run_test=FrontierDistanceSuite --report_level=short
• Result: 8 test cases passed, 68 assertions passed

Fixes #979

[Spikeone]

Just asking: Does this by chance also take into account, that objects can change (due to scripts) so an object that is static, could become env.

Also not sure, pineapple trees are also static, are they? They can be passed though.

[DevOpsOfChaos]

Just asking: Does this by chance also take into account, that objects can change (due to scripts) so an object that is static, could become env.

Also not sure, pineapple trees are also static, are they? They can be passed though.

Good point, I added a small regression test for that.

Passable size-0 static objects and environment objects are still treated as passable. Only current static objects with actual blocking behavior affect this reachability check.

No production code change in this follow-up, just test coverage.

Validation:

• built Test_integration
• ran FrontierDistanceSuite: 8 test cases, 70 assertions passed
• git diff --check

[Flamefire]

Double checked and looks good. Just a few minor comments.

The first on is because it confused me to now have 3 classes:
PathConditionHuman, PathConditionReachable, PathConditionReachableWithStaticBlockers and why the code of this new one can't be in the existing one(s).
So this needs at least a comment

[DevOpsOfChaos]

Addressed the remaining minor review comments.

I added a short explanation for PathConditionReachableWithStaticBlockers, simplified the repeated corridor loops with helpers::range(...), and used RTTR_FOREACH_PT for the full-map setup loop.

Validation:

• built Test_integration
• ran FrontierDistanceSuite: 8 test cases, 70 assertions passed
• git diff --check upstream/master...HEAD