feat: scheduled agent execution via activity-core (WP-0006, v1.3.0)

Enable kaizen agents to run on a regular cadence against a preselected repo
roster, orchestrated by activity-core and prepared by kaizen-agentic — without
this repo owning cron, Temporal workers, or an LLM runtime.

CLI + module:
- src/kaizen_agentic/schedule.py — .kaizen/schedule.yml parse/validate/scaffold
- `kaizen-agentic schedule` group: init, validate, list, prepare <agent>
  (prepare bundles agent prompt + memory + metrics + repo pointers, offline)
- tests/test_schedule_cli.py — 15 tests

Contract & design:
- ADR-005 scheduled agent execution; schema doc + example manifest
- discover_kaizen_scheduled_repos resolver spec, state-hub roster fields,
  kaizen.schedule.prepared event payload, activity-core handoff checklist
- INTEGRATION_PATTERNS Pattern 2 extended with roster model

ActivityDefinition drafts (enabled: false):
- weekly-coach-orientation, weekly-optimization-review

Docs: agency-framework, CLI cheat sheet, PACKAGE_RELEASE runner prereqs,
EcosystemIntegration, CHANGELOG, TODO. Workplan closed (status: done).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/integrations/state-hub-roster-fields.md

@@ -0,0 +1,64 @@
+# State Hub Roster Fields for Kaizen Scheduling (Design)
+
+**Status:** design only — implemented in `the-custodian/state-hub`, not here
+(repo boundary). This document specifies what kaizen-agentic and activity-core
+need from the hub so the State Hub team can add the fields and filter.
+
+## Problem
+
+activity-core's resolver needs to answer: *which registered repos participate in
+kaizen fleet scheduling, and where do they live on disk?* Today state-hub knows
+the canonical repo list and `host_paths` but has no notion of schedule opt-in.
+
+## Existing hub data (sufficient for v1)
+
+`GET /repos/` already returns, per repo:
+
+| Field | Use |
+|-------|-----|
+| `slug` | Canonical repo identifier (`target_repo` in tasks) |
+| `host_paths[hostname] → local_path` | Where the repo is checked out on a runner |
+| `domain` | Scope filter (e.g. `custodian`) |
+
+For **v1**, opt-in is detected **in the repo** (`.kaizen/schedule.yml` exists and
+validates). The resolver clones/reads each candidate path and checks for the
+file. No hub schema change is strictly required to ship the pilot.
+
+## Proposed hub fields (v2, optional)
+
+To let operators query eligibility **without touching every checkout**, add an
+optional repo-metadata flag:
+
+| Field | Type | Default | Meaning |
+|-------|------|---------|---------|
+| `kaizen_schedule_enabled` | bool | `false` | Operator-confirmed fleet participation |
+| `kaizen_schedule_updated_at` | timestamp | null | Last time schedule.yml was synced/seen |
+
+### Suggested filter
+
+```
+GET /repos/?kaizen_schedule_enabled=true&domain=custodian
+```
+
+Returns only schedule-eligible repos with their `host_paths`, so the resolver
+skips repos that have not opted in — cheaper than scanning every checkout.
+
+### Write path
+
+The flag is set by an operator (or a future `kaizen-agentic schedule register`
+that calls the hub). It is **advisory**: the authoritative opt-in remains the
+presence of a valid `.kaizen/schedule.yml` in the repo, re-checked by the
+resolver at run time. The flag is an index, not a source of truth.
+
+## Boundary
+
+- kaizen-agentic does **not** write these fields in WP-0006.
+- state-hub schema migration is tracked in `the-custodian`.
+- The resolver (activity-core) treats the hub flag as a pre-filter and the repo
+  file as the decision.
+
+## Related
+
+- [discover-kaizen-scheduled-repos.md](discover-kaizen-scheduled-repos.md)
+- [schedule-schema.md](schedule-schema.md)
+- [ADR-005](../adr/ADR-005-scheduled-agent-execution.md)