Break up processors.ts mega-functions

[JSONbored]

Context

Part of the review-stack architecture audit (parent epic — layering dimension).
src/queue/processors.ts is 15,241 lines / 202 top-level functions in one file. Three functions account
for a disproportionate share of the debugging cost:

• maybePublishPrPublicSurface (:8608-11239) — 2,631 lines, 17% of the entire file, in one
  function, up to 10 levels of nesting (indentation histogram: 155 lines at 14-space, 79 at 16, 67 at
  18, 17 at 20). It's the most cross-referenced function name in the file's own comments (dozens of
  other functions say "see maybePublishPrPublicSurface's own X block"), meaning most cross-cutting
  review-pipeline concerns live as unnamed inline blocks in one function rather than named,
  independently-testable steps.
• processGitHubWebhook (:5679-6624, 945 lines) — the top-level webhook router, inlines the
  reopen-reclose/draft-dodge/review-evasion trigger conditions directly alongside dozens of other
  event/action branches.
• runAgentMaintenancePlanAndExecute (:2795-3513, 718 lines) — threads ~30 locally-computed values
  into one giant planAgentMaintenanceActions(...) call.

Concrete cost already demonstrated this session: finding the close-enforcement authorization bug
(see linked issue) required diffing 5 near-identical ~200-line functions 700+ lines apart in the same
file to notice one was missing 2 lines the other 4 have — exactly the "grep archaeology" cost this issue
exists to eliminate. Nothing in the file's structure (no section index, no cross-linking beyond prose
comments) surfaces that to a reader not specifically comparing all five.

Fix

No behavior change — pure extraction:

1. maybePublishPrPublicSurface: extract the already comment-delimited blocks (dry-run-chokepoint
   gating, unified-comment feature resolution, AI-vision BYOK gate, manifest-policy evaluation, finding
   attachment, publish-suppression) into named, independently-testable functions called in sequence.
2. processGitHubWebhook: split into per-event-type handlers with the router reduced to dispatch.
3. runAgentMaintenancePlanAndExecute: reduce the parameter surface passed into
   planAgentMaintenanceActions, likely via one options-building helper.

Acceptance criteria

• No behavior change (verified via existing test suite passing unmodified, plus a diff review
  confirming pure extraction).
• maybePublishPrPublicSurface reduced to an orchestration function calling named steps.
• processGitHubWebhook reduced to dispatch only.
• Coverage maintained at 100% patch coverage for any touched lines.

Given the size, this is expected to land as multiple sequential PRs (one per function) rather than one
PR — each PR must pass the full local gate independently.

[linear-code]

JSO-3387

[JSONbored]

Part 1 of 3 done: PR #4688 extracts runAgentMaintenancePlanAndExecute's ~30-value planAgentMaintenanceActions input assembly into a named buildAgentMaintenancePlanInput helper. Verified byte-faithful field-for-field against the removed inline object literal before merge. Deliberately did not also extract the contributor-cap resolution block (async, side-effecting, not called out by the issue text) — kept the scope to exactly what was specified given this file's live-webhook stakes.

Remaining: processGitHubWebhook (945 lines) and maybePublishPrPublicSurface (2,631 lines) — the latter especially needs to be broken into its own sequence of PRs given the size.