API-only deployments (PROCESS_ROLE=api) silently strand enabled agent schedules with no worker to run them

[graysoncooper]

Startup registers both trigger_daemon and agent_schedule_scheduler only when _role_enabled("all","worker") is true. For PROCESS_ROLE=api, neither schedule consumer is registered, yet FastAPI startup completes normally, logs "all background tasks created!", and reports healthy. There is no readiness check that enabled/retained schedules actually have a consumer. This PR also removed the schedule-to-trigger migration step from restart.sh, so retained AgentSchedule rows still depend on the worker-only scheduler.

Where:

Clawith/backend/app/main.py

Lines 307 to 326 in 5564700

	task_specs = []
	if _role_enabled("all", "worker"):
	task_specs.extend([
	("trigger_daemon", start_trigger_daemon()),
	("agent_schedule_scheduler", start_scheduler()),
	])
	if _role_enabled("all", "connector"):
	task_specs.extend([
	("feishu_ws", feishu_ws_manager.start_all()),
	("dingtalk_stream", dingtalk_stream_manager.start_all()),
	("wecom_stream", wecom_stream_manager.start_all()),
	("wechat_poll", wechat_poll_manager.start_all()),
	("discord_gw", discord_gateway_manager.start_all()),
	])
	for name, coro in task_specs:
	task = asyncio.create_task(coro, name=name)
	task.add_done_callback(_bg_task_error)
	logger.info(f"[startup] created bg task: {name}")
	logger.info("[startup] all background tasks created!")

(restart.sh at HEAD no longer contains the schedule-to-trigger migration; only the alembic and langgraph-checkpoint migrations remain.)

Failure scenario: an API-only deployment with previously enabled schedules starts up green. The schedules stay "enabled" in the UI/DB and remain due indefinitely because nothing consumes them, so scheduled automation silently never fires.

Suggested fix: add a startup/readiness check that fails (or warns loudly) when an API-only process has enabled retained schedules but no configured worker consumer, or allow an explicitly configured worker consumer to be attached in that role.

Found while running Ito (AI code review, free for open source) against recently merged PRs — full analysis: https://app.ito.ai/share/ae0ea7b1-78ef-4343-9366-c38491dc0227.

[yaojin3616]

Confirmed: PROCESS_ROLE=api intentionally starts neither trigger_daemon nor agent_schedule_scheduler (backend/app/main.py:308-312), while the Tasks API continues to persist enabled AgentSchedule rows. Commit 6a7fa91b also explicitly removed the restart-time migration because schedules created after startup must still be consumed by the worker.

This needs a deployment-contract decision before a safe fix can be made:

1. reject an API-only process whenever schedules exist (but that can falsely fail a healthy API replica paired with a separate worker);
2. log a warning only (visible but not readiness-safe); or
3. add a cluster-aware worker heartbeat/readiness signal (a broader runtime-coordination change).

Please confirm the supported topology: must every deployment with enabled schedules include a worker replica, and should API replicas be able to verify that remotely? Once that contract is chosen, the appropriate check can be implemented and tested.