Worker health: cold-start grace period

[tydinjarman]

Supersedes part of #19, per your review: the "cold-start handling belongs in worker-health behavior" change, rebuilt from current main through the responsibility architecture, with no helper scripts.

What it does

• WorkerHealthResponsibility.directives now checks _within_cold_start_grace(state) after the stuck/off-track thresholds are met: while the active worker is younger than cold_start_grace_seconds, it emits CONTINUE ("active worker is within the cold-start grace period", priority 900) instead of STEER_WORKER/STOP_WORKER.
• New typed FactoryConfig field cold_start_grace_seconds (default 0.0 = disabled, preserving upstream behavior; FOREMAN_COLD_START_GRACE_SECONDS), plumbed through the core.worker-health responsibility settings in _SETTING_FIELDS.
• Fail-closed: a worker with no recorded start time is never treated as young.

Validation

• 7 new tests in tests/test_worker_health_cold_start.py; full suite 176 passed, ruff check clean.
• This is 1 of 3 focused replacements for Policy: cold-start grace, sticky finish thresholds, optional EMA score smoothing #19 (sticky completion, score smoothing). All three touch builtin.py in disjoint regions, but if merged in sequence the later ones may need a trivial rebase — happy to rebase on request.

[JARosen]

Cold-start hysteresis belongs in core.worker-health, but the current condition is broader than the rationale. It suppresses both worker_stuck and work_off_track solely based on worker age. A young worker that has already produced strong evidence of going in the wrong direction would therefore be allowed to continue.

Please narrow this to the actual cold-start case—for example, defer stuckness while the worker is young and has produced little or no activity—without suppressing evidence-backed off-track intervention. A policy-level test combining age, output or activity, and a high off-track score would help establish the intended safety boundary.

[tydinjarman]

Addressed the cold-start review feedback (pushed as commit 16e0676).

The grace now applies only to worker_stuck and only while the worker is
young and quiet — captured stdout+stderr at most
cold_start_quiet_output_bytes (new knob, default 0, env
FOREMAN_COLD_START_QUIET_OUTPUT_BYTES). An evidence-backed
work_off_track signal always intervenes regardless of worker age; a young
worker that has produced strong evidence of going the wrong way is steered or
stopped immediately. A worker with no recorded start time fails closed toward
the established behavior, and when both checks fire outside grace, the
evidence-backed off-track verdict now takes precedence over the
max-confidence tie-break.

Test evidence: full suite 180 passed, including 4 new policy-level tests —
off-track never suppressed for a young quiet worker, off-track still fires
for a young worker with output and a high off-track score (your
safety-boundary case), activity disqualifying stuckness deferral, and the
quiet-output-bytes boundary. Ruff clean.

[JARosen]

Thank you for being so responsive and for narrowing the grace period to young, quiet stuckness. The revised off-track behavior addresses the original safety concern.

One cross-responsibility arbitration issue remains. Deferred stuckness currently proposes a priority-900 CONTINUE carrying the stuck confidence. Because policy breaks equal-priority ties by confidence, that deferral can suppress another responsibility actionable directive. I reproduced a 0.95 cold-start stuck score selecting CONTINUE over a 0.85 repository.instructions STEER_WORKER proposal.

Please make cold-start deferral abstain from proposing a directive, or use a priority that cannot override actionable responsibility output. If no other responsibility fires, the policy already supplies its ordinary priority-zero CONTINUE. Please add a policy-level regression test combining deferred stuckness with repository drift.

This remaining change is small. If you would prefer that I make it, say so and I am happy to help rather than taking over the branch without asking.