docs: a Cloud Tasks and EventBridge migration guide

[kartikeya-27]

The user most likely to adopt the push executor (#849) is not currently running a queue at all.
They are on Cloud Run, Lambda or App Engine, using Cloud Tasks or EventBridge to POST to an HTTP
endpoint, and they are already running exactly the topology HttpDispatchTarget provides.

For them the pitch is unusually clean: keep the handlers, keep the platform, change what
dispatches. So this guide is the on-ramp for the push work, and it should be written with it.

Cover:

• a Cloud Tasks queue → a FlexiQ queue with an HTTP dispatch target
• the task's HTTP target and OIDC token → the target URL and its outbound auth (security: an SSRF allowlist and outbound auth for push dispatch #844)
• retry configuration → the retry policy, with the differences in backoff semantics spelled out
• scheduleTime → delayed enqueue; dispatchDeadline → the push request deadline and Settle
  (grpc: a Settle callback for work that outlives the request deadline #845)
• EventBridge rules and targets → triggers (triggers: HTTP, object-store and cron as enqueue sources #847)

And what they gain by moving, which is the real argument:

• a dead-letter queue that can be inspected and replayed, not just a bucket things fall into
• durable steps, which the platform has no equivalent of
• cancellation of in-flight work (core: cancellation in push mode #846)
• the same queue reachable from a long-lived worker, not only from an HTTP handler
• it runs locally, which Cloud Tasks does not

Blocked on the push executor. File-and-wait, not file-and-forget: writing the guide is how the
push design gets checked against a real migration path.