Add world-worker obstacle awareness

[SimGamerJen]

Summary

Builds directly on the validated continuous-follow checkpoint and adds conservative environment sensing before any attempt at obstacle avoidance/pathfinding.

Behaviour

• adds HP_WorldObstacleAwareness.lua
• uses a forward, worker-width overlapBox corridor rather than a centre-line ray
• collision mask intentionally limited to STATIC_OBJECT, BUILDING, and VEHICLE
• moving workers stop before a detected obstruction
• one-shot walk/curve/goto motion ends with obstacle-blocked
• FOLLOW enters a persistent blocked state instead of immediately restarting the motion
• while FOLLOW is blocked, the current direct route to the moving player is rechecked
• FOLLOW resumes only after the direct corridor remains clear for ~350 ms
• target player is not part of the obstacle mask, avoiding false blocking on the person being followed
• worker's own graphics subtree is ignored defensively

Diagnostic command

• hpWorld sense [slot]

This reports whether the worker's immediate forward corridor is CLEAR or BLOCKED, plus the hit node/name/group where available.

Scope

This PR is deliberately stop/hold only. It does not choose a route around an obstacle, create waypoints, or add navmesh/pathfinding.

Test focus

1. Confirm [WorldObstacle] Loaded ... obstacle-awareness-1 appears without Lua errors.
2. Place A in open ground and run hpWorld sense A; expect CLEAR.
3. Face A toward a parked tractor, wall/shed, and fence from roughly 1 m away; hpWorld sense A should report BLOCKED for each collidable obstacle.
4. Put an obstacle between A and the player, then run hpWorld follow A; A should stop before contact and enter FOLLOW STATE A -> blocked.
5. Stay behind the obstacle for several seconds; A should remain stopped rather than repeatedly restarting.
6. Move so the direct route clears; after a short confirmation delay, expect OBSTACLE CLEAR and FOLLOW should resume automatically.
7. Repeat with a parked vehicle and a static building/fence if practical.
8. Verify normal follow behaviour remains unchanged where the path is clear.

No pathfinding/avoidance is introduced yet.

[SimGamerJen]

Live test found a blocked-follow edge case. The blocked-state recheck correctly tested the new direct route to the player, but on resume the normal obstacle wrapper immediately tested the worker's old/current facing before curved locomotion had time to steer. This produced CLEAR -> FOLLOW RESUME -> immediate OBSTACLE STOP loops when the worker was still facing the original object.

Refinement added on this PR:

• new HP_WorldObstacleTurnEscape.lua
• if the target/follow corridor is clear but the current facing corridor is still blocked, the worker now turns in place at the validated bounded-yaw rate
• forward speed remains zero during that turn
• normal walking resumes only once the worker is aligned to the clear route
• if the target corridor becomes blocked again during the turn, control falls back to the normal blocked/hold logic

Expected new diagnostics:

• OBSTACLE TURN START ...
• OBSTACLE TURN COMPLETE ...; forward route clear

This keeps PR #25 stop/hold-only with respect to path selection: it still does not route around obstacles; it only prevents stale facing from falsely re-blocking an otherwise clear follow route.

[SimGamerJen]

Second live obstacle-follow test with obstacle-awareness-2 / obstacle-turn-escape-2 shows the turn-before-walk layer now activates, but still releases too early in some cases. Example sequence: OBSTACLE TURN START -> TURN COMPLETE -> ~0.4-0.8 s of movement -> OBSTACLE STOP on the same cultivator, repeated until the worker has rotated far enough to escape.

Root cause isolated: the blocked FOLLOW recheck and current-facing precheck use the prospective walking corridor, but targetBlocked inside HP_WorldObstacleTurnEscape.lua was still using a zero-speed/stationary probe. This allowed TURN COMPLETE while only the short target corridor was clear.

Refinement committed:

• HP_WorldObstacleTurnEscape bumped to 2.2.0.0-alpha4-obstacle-turn-escape-3
• both current-facing and target-facing turn-release checks now use the same prospective walking speed (Loco.walkSpeed, currently 1.35 m/s)
• TURN COMPLETE now means the full walking corridor is clear, not merely the stationary overlap box
• diagnostic completion log now includes probeSpeed and states walking corridor clear

Expected result: after a blocked FOLLOW route becomes genuinely clear, the worker should turn in place and then transition directly into continuous locomotion without the repeated short restart/stop cycles.

[SimGamerJen]

Live validation PASS (2026-08-09, obstacle-turn-escape-3). Test against John Deere cultivator980: A/Rhys stopped correctly on cultivator980_main_component1, held while blocked, then resumed only after the matched 1.35 m/s walking corridor cleared. Sequence: OBSTACLE CLEAR -> FOLLOW RESUME -> OBSTACLE TURN START -> OBSTACLE TURN COMPLETE ... probeSpeed=1.35; walking corridor clear -> continuous curved locomotion. No subsequent obstacle stop occurred against the implement after moving off; Rhys followed normally and reached the 1.80 m stand-off. This validates the turn-before-walk hand-off fix.