#9747 fix(logs): log the webhook poll id and emitted event id under their own names

Summary

• Found in the v0.9.45 release review: webhook polls and Sim events logged their own generated ids as requestId. The logger lets the request context own that field, and both run inside the poll route's request context, so the poll id and the per-event id never reached a log line
• The poll orchestrator names its per-poll id pollId and binds it on the handler logger with webhookId, so every handler line carries it
• Drops the per-line { requestId } fields from all eight polling handlers and skipAdmissionRefusedPoll, plus the helper params and the HubSpot filter-limit error prefix that only fed them
• The Sim event emitter logs its per-event id as dispatchId
• The ids passed downstream are unchanged: each poll still passes its id as requestId to processPolledWebhookEvent and OAuth refresh, and each emitted event still passes its own, so execution request ids and idempotency keys stay unique per poll and per event
• add-trigger skill: polling handlers log through ctx.logger and never add { requestId }

Type of Change

• Bug fix

Testing

• Existing polling tests (gmail, google-calendar, hubspot, imap, rss, orchestrator, utils) and workspace-events/emitter.test.ts pass
• biome, check:source-conventions, check:comment-hygiene, check:test-patterns, check:utils; type-check via the pre-push hook

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)