lock worktree/PR off for the non-committing coordinator task types

[atomantic]

Summary

A branch-cleanup CoS run did its whole job — pruned stale tracking refs, deleted the one fully-merged local branch, correctly skipped the protected and worktree-held ones — and was still recorded as failed with pr-missing.

Root cause: branch-cleanup was the only git/gh coordinator type shipping with no taskMetadata at all. applyAppWorktreeDefault fills useWorktree/openPR on an === undefined check, so it took them from the managed app's defaultOpenPR: true. Every run got a CoS-managed worktree it never cds into (holding the very refs it was trying to delete) plus a PR expectation a branch-deletion task can never satisfy, and finalization scored the completed run pr-missing.

The four non-committing coordinator types — branch-cleanup, branch-reconcile, issue-reconcile, jira-status-report, already enumerated in NON_COMMITTING_COORDINATOR_TASK_TYPES for their commit-criterion exemption — now share one documented posture:

• useWorktree / openPR explicitly false, not merely absent, so the app defaults can't fill them; locked in MANAGED_AGENT_OPTIONS so a per-app override can't re-attach them.
• worktreeChangesExpected: false — a clean tree is the success shape for a branch deletion or a posted report, so the TUI idle-complete gate must not read it as "the model produced no work". Managed as well, because loadSchedule preserves an explicit taskMetadata: null (skipping the defaults deep-merge) and enforceManagedAgentOptions rebuilds only the managed fields — unmanaged, it would silently go absent on that path and reintroduce idle-no-changes.

jira-status-report was hit by the same bug for a subtler reason worth calling out: its readOnly: true skips worktree creation (agentWorkspacePrep.js) but the finalize-time PR-claim check reads metadata.openPR directly (agentTuiSpawning.js), so a posted report still scored pr-missing.

A guard test iterates NON_COMMITTING_COORDINATOR_TASK_TYPES rather than a hand-typed list, so a future coordinator type can't be added to one place and not the other — which is exactly how this shipped.

No migration needed. Existing installs converge on the next schedule load: the taskMetadata deep-merge backfills the new keys, and enforceManagedAgentOptions rewrites any stored true.

Test plan

• cd server && NODE_ENV=test npx vitest run — 24,334 passed, 211 skipped (DB suites gated off the non-test database as designed).
• 8 new tests in taskSchedule.test.js, both parameterized off the real NON_COMMITTING_COORDINATOR_TASK_TYPES set:
  • each type declares the posture and locks all three flags;
  • each type keeps the full posture through a stored taskMetadata: null.
• Both guards verified falsifiable, not just green: removing jira-status-report's lock fails the first; dropping worktreeChangesExpected from the managed list fails the second for all four types.
• Plus per-type coverage that loadSchedule forces stored useWorktree/openPR: true back off, and that a per-app override is stripped.
• Reviewed by codex (gpt-5.6-terra) and a local ollama model; codex's one finding (the taskMetadata: null path) is fixed in this branch and confirmed clean on re-review.