feat: enable scheduled content sync with typo3 for mcp

config/packages/zenstruck_schedule.yaml

@@ -67,3 +67,15 @@ when@prod:
       - task: app:bpn:sync-contingents
         frequency: "5 20-23,0-7 * * *"
         description: "Syncs the full contingent horizon hourly outside peak hours"
+
+      - task: app:content:sync
+        frequency: "0 * * * *"
+        description: "Mirrors changes in the TYPO3 content feed for the chatbot MCP server"
+
+      - task: app:content:sync --refresh
+        frequency: "5 1 * * 0"
+        description: "Refetches TYPO3 content stored more than 7 days ago, within the night window"
+
+      - task: app:content:check-freshness --max-age 150
+        frequency: "10 * * * *"
+        description: "Fails when the TYPO3 content mirror has missed more than one hourly sync"

docs/chatbot-mcp.md

@@ -100,8 +100,12 @@ php bin/console app:content:sync --ignore-window  # deliberate bulk run outside
 php bin/console app:content:check-freshness       # fails if the last good manifest is > 60 min old
 ```
 
-Not scheduled yet. The intended schedule is a delta sync every 15 minutes, `--refresh` on Sunday at
-01:00, and the freshness check hourly, so that `email_on_failure` reports a stalled sync.
+Scheduled on prod (`config/packages/zenstruck_schedule.yaml`): an hourly delta sync,
+`--refresh` on Sunday at 01:05, and the freshness check hourly at :10 with `--max-age 150`, so that
+`email_on_failure` reports a stalled sync but not a single missed run. Website content changes
+rarely, and an hour's delay is acceptable for the chatbot; trip data and availability do not come
+from this mirror. The refresh is off the quarter hour because a run that
+finds another one holding the lock exits successfully without doing anything.
 
 The feed is read with `X-Api-Key: <APP_CMS_API_KEY>` from `APP_CMS_API_BASE_URL`. The manifest lists
 every site whichever host serves it. The key is only sent to hosts of the sites the manifest names.