feat(orb): dispatch config_push relay rows separately from the GitHub-webhook queue

[JSONbored]

Context

Once the companion write-side issue adds a kind column to orb_relay_pending, the pull-drain loop
must stop assuming every drained row is a GitHub webhook. Today,
drainOrbRelayWithMonitor's per-event loop (src/selfhost/monitored-work.ts, ~L88-113)
unconditionally calls args.enqueue(env, deliveryId, eventName, rawBody), which resolves to
enqueueWebhookByEnv (src/github/webhook.ts) — this always does
JSON.parse(rawBody) as GitHubWebhookPayload. A config_push-kind row's rawBody is not a GitHub
webhook payload, so without a branch here it would either throw or be silently misinterpreted.

⚠️ Hard constraint, read before starting: the existing GitHub-webhook dispatch path
(kind = 'github_webhook' or any row predating the kind column, which defaults to that value)
must be provably unchanged by this issue. A regression here breaks every self-host container's
real-time review pipeline, not just the new feature. Do not restructure enqueueWebhookByEnv
itself — only add a branch before it is called.

Requirements

1. In drainOrbRelayWithMonitor's per-event loop, branch on ev.kind (or equivalent field once the
   companion write-side issue lands) before calling args.enqueue(...):
   • kind === 'github_webhook' (or the column's default) → existing behavior, byte-for-byte
     unchanged.
   • kind === 'config_push' → route to a new, small, dedicated handler instead.
2. The new config_push handler's v1 scope is receive-and-surface only — per Add a config-push/rollout-control write path to fleet analytics #4902's own design
   comment, do not implement any capability-toggle or config-mutation side effect in this issue
   (that's explicitly deferred as separate, not-yet-scoped follow-up work). "Surface" means: log the
   received push (structured log, matching this codebase's existing console.warn/console.error
   JSON-shaped logging convention in this same file) and make it visible via whatever this repo's
   existing self-host observability surface already picks up structured logs through.
3. No new persistence beyond what the companion issue already added — this issue is dispatch logic
   only.

Deliverables

• kind-based branch in drainOrbRelayWithMonitor's per-event loop, before the existing
  args.enqueue(...) call
• New config_push handler (distinct function, not inline), doing only receive-and-log for v1
• Regression test proving a kind = 'github_webhook' (and a legacy/no-kind-set) row still
  dispatches through the exact existing enqueueWebhookByEnv path, unchanged
• Test proving a kind = 'config_push' row reaches the new handler instead, and does not
  attempt to JSON.parse it as a GitHubWebhookPayload

Test Coverage Requirements

src/selfhost/monitored-work.ts is under src/** — full 99%+ Codecov patch/branch gate applies.
Both branches of the new kind dispatch need explicit coverage, plus the existing
drainOrbRelayWithMonitor test suite must continue passing unmodified (proving no behavior drift
for the default/webhook path).

Expected Outcome

A config_push-kind relay row reaches a dedicated handler instead of being incorrectly parsed as a
GitHub webhook payload. Every existing webhook event continues to flow through the exact same path
as before this issue, with zero observable behavior change.

Links & Resources

• Parent: Add a config-push/rollout-control write path to fleet analytics #4902 (design comment, 2026-07-18) — this issue implements piece 2 of that comment's
  3-piece breakdown
• Blocked by: the companion write-side issue (adds the kind column and payload shape)
• src/selfhost/monitored-work.ts's drainOrbRelayWithMonitor (~L61-113) — the loop this modifies
• src/github/webhook.ts's enqueueWebhookByEnv — the existing path that must stay untouched for
  webhook-kind rows

[linear-code]

JSO-5348