follow-up(gh-channel): agent-facing GitHub events skill + channel adapter

[jaylfc]

Follow-up to #336. Once the webhook receiver + JSONL event log lands as operator tooling, the same plumbing can be exposed to coding agents working on dev projects.

Two halves

Inbound (agent ← GitHub events) — this issue

The webhook receiver from #336 already produces a clean JSONL stream of `pull_request`, `issue_comment`, `pull_request_review`, `check_run`, `check_suite` events. Build on top:

1. Channel adapter in the existing channel-hub (`tinyagentos/channel_hub/`) that consumes the JSONL log and routes events to subscribed agents — same shape as the Slack / Discord / Telegram adapters that land in the Phase 3 comms work.
2. Agent-side skill — `gh:wait_for_ci`, `gh:on_pr_comment`, `gh:on_review` — that blocks the calling agent's loop until a matching event fires. Push-style feedback instead of agents polling `gh` themselves.
3. Scope gates on the new bearer-token taxonomy (introduced in Pass 1 feat(agents): per-agent API tokens + bearer auth + REST endpoints (audit Pass 1, Phase 1) #450): `gh.events.subscribe`, `gh.events.wait`. Default `["*"]` covers them; narrow agents must opt in.
4. Symmetry note: Pass 1 shipped `ui.notify` as the first agent → user primitive. This is the corresponding external → agent primitive.

Outbound (agent → GitHub actions) — separate issue, not this one

Per-agent GitHub tokens (or a delegated GitHub App), scope gating (`gh.pr.create`, `gh.comment.write`, `gh.issue.write`), and a secrets vault for the delegated credentials. That is bigger — it wants its own design pass and a real threat model. Open as its own issue when there is a concrete need.

Why this matters

Coding agents (Claude Code lead/orchestrator, agents the user spawns for dev projects, future store-installed dev-helper agents) want tight real-time feedback on CI / review activity during long PR cycles. Today an agent that opens a PR and waits has to either sleep + poll the `gh` CLI or burn context on retries. With this skill, the agent yields its loop until the event fires and resumes immediately. Same value proposition as #336 has for the human operator.

Acceptance criteria sketch

• `tinyagentos/channel_hub/adapters/github.py` (or equivalent) tails the JSONL from infra(notifications): webhook receiver for repo-wide GitHub events (CI / comments / reviews) #336 and emits to the channel-hub router
• Agents can subscribe to event filters scoped to (repo, pr_number, kind)
• Skill or REST endpoint that blocks until a matching event arrives (configurable timeout)
• Conformance test: open a fake event in JSONL, agent's `gh:wait_for_ci` returns within the test timeout
• Documented in `docs/agents/recipes/waiting-for-ci.md`

Cross-references

• Foundation: infra(notifications): webhook receiver for repo-wide GitHub events (CI / comments / reviews) #336 (operator-tooling-only delivery — webhook receiver + JSONL log)
• Pass 1 agent-friendliness audit: feat(agents): per-agent API tokens + bearer auth + REST endpoints (audit Pass 1, Phase 1) #450 (introduces the scope taxonomy and the `docs/agents/recipes/` pattern)
• Channel hub adapters: existing pattern in `tinyagentos/channel_hub/adapter_manager.py`