fix(doctor): cronjob always shows 'system dependency not met'

[ygd58]

Summary

Fixes #878

hermes doctor always showed ⚠ cronjob (system dependency not met) even on fully working installations.

Root Cause

check_cronjob_requirements() gates on HERMES_INTERACTIVE (and two other env vars) that are set by the CLI at startup — but hermes doctor never sets them. So the check always returns False.

The env-var gate is correct for runtime: cronjob tools only make sense in an interactive or gateway session. The bug is that the doctor check runs without that context.

Fix

Temporarily set HERMES_INTERACTIVE=1 for the duration of check_tool_availability() in doctor, then restore the original env state. One line of change in the right place — no changes to the tool's own logic.

This is safer than modifying check_cronjob_requirements() itself, which would affect runtime gating behavior.

Before:

[ygd58]

Both #884 and #895 use the same os.environ.setdefault("HERMES_INTERACTIVE", "1") approach. Differences:

• This PR uses setdefault scoped to run_doctor() so it applies for the entire doctor session, not just the tool-availability check avoids the case where a later check also needs the var set
• This PR has 2 tests: one verifying the fix itself, one verifying setdefault doesn't override an existing HERMES_INTERACTIVE value (important for callers that already set it)
• This PR is rebased on latest main (as of today), no conflicts

Happy to close in favour of #895 if preferred just flagging the test coverage difference.

[ygd58]

Closing — this fix was independently implemented in upstream main (hermes_cli/doctor.py line 102). The approach is identical: os.environ.setdefault("HERMES_INTERACTIVE", "1") in run_doctor(). Issue #878 is resolved.