refactor: route workflow wake through chat delivery

[shuxueshuxue]

Summary

Removes the duplicated local workflow direct-wake path from durable chat communication.

Durable communication is now one path:

1. cel send-message / group workflow notification writes a backend chat message.
2. The backend chat dispatcher emits runtime notifications for the addressed recipient.
3. The local daemon subscriber streams those notifications into the local inbox.
4. The daemon wakes any registered terminal surface.
5. Provider hooks attach metadata/read/reply commands; the agent reads/replies through cel read-message / cel send-message.

Explicit local terminal operations, such as cel group <id> supervisor wake, remain explicit wake controls. They are not durable chat message delivery.

Local verification

• uv run ruff check .
• uv run ruff format --check .
• uv run pytest tests/test_cli_chat_commands.py tests/test_group_chat_transport.py tests/test_daemon_wake.py tests/test_daemon_subscriber.py -q
• uv run pytest -q → 467 passed

YATU proof

Mac mini isolated run, fresh clone of this branch, isolated MYCEL_HOME, real backend https://mycel.nextmind.space, real cel codex running in tmux:

• created pr500-a-20260506023333 and pr500-b-20260506023333
• launched B with branch CLI: uv run cel codex --identity pr500-b-20260506023333
• sent from A via backend-only cel send-message @pr500-b-20260506023333 ...
• B daemon subscriber appended the backend notification and recorded wake.sent
• tmux capture showed B received the wake, provider hook attached Mycel metadata, B ran cel read-message, then B replied with cel send-message

Evidence artifact is outside the repo: ~/share/mycel-yatu/pr500-backend-wake-20260506023333 on mac mini.