[liuedcson]

Background

CronCreateOptions declares statusReason, and parsePersistedJob validates the
field when a record is loaded:

if (candidate.statusReason !== undefined && candidate.statusReason !== "session_missing") return undefined;

create() did not write it. Only update() did. The type therefore promised a
field that the create path silently dropped.

Found while verifying the merged desktop scheduled-task feature. Its migration
imports a task whose bound session is already gone as
{ status: "paused", statusReason: "session_missing" }, so the import relied on a
create-with-reason that did not persist it. The task still appeared paused, which
is why the symptom was a missing explanation rather than a wrong status — the
import path happens to write the store directly today, so nothing was visibly
broken, but any host using the documented option lost the field.

Fix

packages/coding-agent/src/features/step-cron.ts — write statusReason in
create() beside status:

...(options.status ? { status: options.status } : {}),
...(options.statusReason ? { statusReason: options.statusReason } : {}),

The guard mirrors status: an absent reason adds no field, and the record reader
still rejects any value other than session_missing.

Verification

• pnpm exec vitest --run test/step-cron.test.ts: 60 passed (one new test).
• The new test fails with the fix reverted and passes with it, so it pins the
  behaviour rather than restating the implementation: it creates a task with
  status: "paused" and statusReason: "session_missing", reloads the store, and
  asserts both fields survive.
• tsgo -p tsconfig.json --noEmit: clean.
• Biome check --error-on-warnings and the pre-commit guard set: pass.

Boundary

One field on one write path. No schema change, no migration, and no change to
update() or the reader.