fix: add per-job allow_silent flag for recurring briefing/report jobs

[Sahil-SS9]

Fixes #53230

Description

Adds a per-job allow_silent flag (default True for backward compatibility) that lets recurring briefing/report jobs opt out of the generic [SILENT] suppression behavior.

When allow_silent=False:

• The [SILENT] suppression instruction is omitted from the cron prompt — replaced with guidance that the job must always deliver
• Any [SILENT] response from the agent is delivered anyway instead of being suppressed

Changes

• cron/scheduler.py: _build_job_prompt() conditionally includes the SILENT instruction based on allow_silent. run_one_job() skips silence detection when allow_silent=False.
• cron/jobs.py: create_job() accepts and stores allow_silent.
• tools/cronjob_tools.py: cronjob() tool accepts allow_silent on create/update, exposes it in _format_job(), and documents it in the schema.

Verification

• All three modified files compile cleanly
• No secrets or personal refs leaked
• Only the 3 intended files changed (59 insertions, 13 deletions)
• Backward compatible: existing jobs without allow_silent default to True (same behavior as before)

[alt-glitch]

This was generated by AI during triage.

Competing with #53252 for the same fix (both implement a per-job allow_silent flag fixing #53230). This PR is the minimal 3-file core variant (cron/scheduler.py, cron/jobs.py, tools/cronjob_tools.py); #53252 is the broader end-to-end variant wiring the flag through blueprints, the dashboard cron-create API, and the api_server cron jobs API. Not a duplicate -- flagging the cluster so a maintainer can choose minimal-fix vs full-surface.

[teknium1]

Thanks for the focused implementation. The issue premise is confirmed on current main: cron/scheduler.py:2263-2276 still injects generic [SILENT] guidance for every cron job, and cron/scheduler.py:3493-3510 suppresses recognized silence responses.

Problems

• The PR changes both contracts without tests. Current tests assert unconditional prompt guidance at tests/cron/test_scheduler.py:2672-2689 and suppression at tests/cron/test_run_one_job.py:69-79; add coverage for allow_silent=False and legacy/default behavior.
• The flag is available only through cronjob. CLI create/edit has no corresponding option (hermes_cli/subcommands/cron.py:26-136), and blueprint job construction does not carry it (tools/blueprints.py:172-194). This leaves those normal creation paths unable to request always-deliver behavior.

Suggested changes

• Apply the delivery predicate to the current run_one_job() block at cron/scheduler.py:3493-3510; that block has moved since this branch's scheduler hunk and now preserves deferred-agent teardown.
• Add persistence, prompt, and delivery regression tests, then either include the intended creation/edit surfaces or retain this explicitly as the minimal tool-only lane alongside #53252.

Automated hermes-sweeper review.

[teknium1]

Please add regression coverage for this newly exposed parameter: create/update round trips, legacy default suppression, and delivery of a recognized [SILENT] response when allow_silent=False.

[Sahil-SS9]

Thanks for the review. I have added the requested regression coverage.

• Create/update round trips — TestAllowSilentFlag in tests/tools/test_cronjob_tools.py covers creating a job with allow_silent=False/True, the legacy default (True), and updating the flag both ways, including that leaving it unspecified on update does not clear it.
• Legacy default suppression — covered by the create-default test.
• [SILENT] delivery when allow_silent=False — added test_silent_response_delivered_when_allow_silent_false to TestSilentDelivery. Writing that test surfaced a real bug: the authoritative (inner) delivery block in run_one_job recomputed should_deliver and suppressed [SILENT] unconditionally, ignoring allow_silent=False. I have aligned it with the outer block so it only suppresses when job.allow_silent defaults to True. Full cron scheduler + cronjob tool suites pass (324 tests).

[Sahil-SS9]

Thanks @alt-glitch for the triage note. #53252 is a different fix (briefing delivery requirement) — not a duplicate. This PR and #53252 address different aspects of the same issue (#53230) and can land independently.