fix: guard webhook canary enqueue semantics

[pilipilisbot]

Summary

• keep webhook-only observations out of queue ingestion unless the structured payload classifies as actionable
• ignore approved pull request reviews and all deliveries sent by configured botLogins
• separate webhookCanaryRepos from the transport-wide enabledRepos gate so a one-repo webhook canary cannot deny IMAP work elsewhere
• persist each canary enqueue decision and linked job, expose them through delivery APIs/filters, and render direct job links in the dashboard
• compare only shared canonical event families inside the retained webhook window, with a configurable grace period
• align failed workflow-run event keys across transports and parse GitHub's #commitcomment-<id> anchors
• bound GitHub actor enrichment calls with a subprocess timeout
• expand literal %h webhook policy paths defensively and fix the systemd environment example

Safety fixes

The canary now fails closed unless a repository appears in webhookCanaryRepos. The existing enabledRepos field keeps its original transport-wide meaning, so IMAP remains unchanged when the webhook canary is narrow.

Configured bot identities are observational only and cannot self-trigger webhook work. Coverage excludes old IMAP history, source-specific email:* fallbacks, unsupported event identities, and deliveries still inside the grace window.

Validation

• python -m pytest -q — 409 passed
• dashboard npm test -- --run — 62 passed
• dashboard npm run build — passed
• migrated a SQLite backup of the production database: integrity ok, 0 foreign-key violations
• corrected production-data coverage query: 55/55 comparable IMAP events matched, 0 IMAP-only, rather than the misleading historical denominator

Rollout

Keep GITHUB_AGENT_BRIDGE_WEBHOOK_MODE=shadow until this lands. Then configure one explicit webhookCanaryRepos entry and switch only the webhook service/dashboard to canary. Rollback is configuration-only: return the mode to shadow.

Requested by: @ecarreras

Follow-up for #233 post-merge audit.

[giscebot]

Approved. I checked the canary gate ordering, bot/self-trigger suppression, non-actionable payload handling before canonical-event claiming, cross-transport identities for failed workflows and commit comments, the SQLite/policy/schema/docs compatibility path, operator authorization, and the dashboard audit links and filters.

Validated at 3fae7bc: 409 Python tests, 62 dashboard tests, production dashboard build, and diff check; CI is green on Python 3.11, Python 3.12, and dashboard.

Non-blocking follow-up: the coverage query applies julianday() to created_at, so a future high-volume ingest_receipts table may need a source/created_at index plus index-friendly comparisons. That does not block the current guarded rollout.