Pause daily-todo-md-stale-review: sole source of the 5 closed Forgejo issues

Traced the origin of the-custodian issues #1-5 (opened 2026-07-08, all
reviewed and closed 2026-07-20): this ActivityDefinition's matched rule
always produces a TaskSpec (rules/actions.py::_task_spec_for_rule), and
RunActivityWorkflow unconditionally routes TaskSpecs through emit_tasks
-> the deployment-wide IssueSink (ISSUE_SINK_TYPE=rest -> issue-core ->
Forgejo). It is the fleet's only consumer of the task_template rule
action -- confirmed via grep across activity-definitions/.

Per current policy (Forgejo issue tracking is not the fleet coordination
mechanism), paused rather than left to recreate the same sidetrack daily:
enabled: false, status: paused, re-enable path documented in the file
(needs a new activity-core report-sink authoring a kind: intake work
record instead of an IssueSink task spec). Added as item 6 to
CUST-WP-0060's stage-3 successor seed, including the reminder to grep the
fleet for any other task_template consumer before stage 3 ships.

This is the ADR-001 file-level fix; the live activity-core DB row and
Temporal schedule pick it up on the next Railiance-deployed
'make sync-activity-definitions' run -- not something I have credentials
or standing to trigger directly from this session.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

workplans/CUST-WP-0060-work-record-canonization.md

@@ -181,3 +181,15 @@ with green proof runs.
    generate *around* them.
 5. Suggestion-table close-out (read-only legacy) once the intake entity is
    live.
+6. **New report-sink for activity-core** (added 2026-07-20, Forgejo-issue
+   housekeeping session): `daily-todo-md-stale-review` was found still
+   routing through the deployment-wide `IssueSink` (`ISSUE_SINK_TYPE=rest`
+   → issue-core → Forgejo) — the only fleet consumer of the `task_template`
+   rule action, and the source of 5 stale-review issues nobody was meant
+   to see (Forgejo issue tracking is not the fleet coordination mechanism).
+   Paused (`enabled: false`) rather than left running; re-enable requires
+   a new activity-core report-sink type that authors a `kind: intake` work
+   record in the target repo (per this workplan's stage-3 promotion
+   design) instead of an `IssueSink` task spec. Any other `ActivityDefinition`
+   that later adds a `rule.action.task_template` inherits the same trap —
+   worth a fleet-wide grep before stage 3 ships.