Expose world-worker movement actions in the WORLD UI

[SimGamerJen]

Summary

Builds directly on the validated obstacle-awareness checkpoint (PR #25) and exposes the already-proven world-worker movement behaviours through the WORLD management screen.

Changes

• adds HP_WorldActionUI.lua as a thin UI adapter over validated Alpha4 movement APIs
• adds COME HERE to the WORLD action bar
• adds dynamic FOLLOW / UNFOLLOW to the WORLD action bar
• shows live movement state in the existing WORLD STATUS column, including FOLLOWING, FOLLOW / WAITING, FOLLOW / BLOCKED, COME HERE and other active motion states
• disables movement buttons when the selected worker has no saved world placement
• COME HERE cleanly cancels continuous FOLLOW for that worker before issuing the one-shot navigation request
• movement remains independent per canonical A-T worker, allowing multiple workers to be placed/following simultaneously

Scope

This PR does not change locomotion, obstacle sensing, collision behaviour, persistence, or the known-good PR #25 controllers. It only exposes existing movement APIs in the management UI and makes their state visible.

Test focus

1. Confirm [WorldWorkerUI] Loaded 2.2.0.0-alpha5-world-actions-ui-1 appears without Lua errors.
2. Open RCTRL+; -> WORLD and confirm the action bar contains CLOSE, PLACE/MOVE HERE, COME HERE, FOLLOW, FACE ME, REMOVE.
3. Select a placed worker and click COME HERE; worker should walk to the normal stand-off and WORLD STATUS should show COMING HERE while moving.
4. Click FOLLOW; button should change to UNFOLLOW and WORLD STATUS should reflect follow state.
5. Click UNFOLLOW; movement should stop cleanly and the button should return to FOLLOW.
6. Place two workers (for example A and K), enable FOLLOW independently on both, and verify both movement states remain independent without Lua errors or one worker cancelling the other.
7. Verify PR Add world-worker obstacle awareness #25 obstacle stop/hold behaviour still works when FOLLOW is initiated from the UI.

Future target architecture

Vehicle destinations are intentionally not implemented here, but this UI/action phase is being kept separate from locomotion so later target types can resolve to world destinations/entry transforms without replacing the movement controller.