Verify MyPlanner and MyProjector stop failing closed once the ask channel is live

[lorenzoliuzzo]

Both currently fail closed in unattended CI for want of an ASK channel — they are the two concrete, already-diagnosed victims of the unplugged ask path.

Once MyThingsLab/my-guard#10 lands and the env is wired, they should be able to post. This issue is the proof case: run both in CI with MYTHINGS_ASK_CMD set and confirm the ASK reaches a human and the run completes instead of collapsing to DENY.

If they still fail closed, the diagnosis was wrong and this epic's premise needs revisiting.

[lorenzoliuzzo]

Tracked by the human-in-the-loop epic: #46

[lorenzoliuzzo]

Verified — and the diagnosis needed revisiting, per the issue's own fallback.

MYTHINGS_ASK_CMD does reach the worker process (fleet_ask.enable() sets it in os.environ, inherited by every subprocess). But neither MyPlanner nor MyProjector ever consulted it: both defined a bare DefaultPolicy implementing mythings.policy.Policy directly, never constructing a myguard.Guard. Only Guard reads MYTHINGS_ASK_CMD and escalates ASK through it before .under(unattended=True) runs — so for these two tools the ask channel was as unplugged as the bot's was before my-guard#10, just one layer over.

Fixed on:

• my-planner#8 — wires myguard.Guard in as the default policy, same rule, plus a proof-case test (MYTHINGS_ASK_CMD=true under GITHUB_ACTIONS=true now performs the tracking-issue edit instead of collapsing to DENY). CI green.
• my-projector#9 — same fix, three rules preserved. CI green.

Both needed my-guard added as a new dependency + CI installing it from git (not on PyPI), same pattern as my-things-core.