docs: a Cloud Tasks and EventBridge migration guide

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 (#844)
• retry configuration → the retry policy, with the differences in backoff semantics spelled out
• scheduleTime → delayed enqueue; dispatchDeadline → the push request deadline and Settle
  (#845)
• EventBridge rules and targets → triggers (#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 (#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.

Start by reading the push executor work and the linked issues #844–#847, especially the outbound auth, deadline/Settle, trigger, and cancellation details. The guide is done when it maps Cloud Tasks and EventBridge concepts to FlexiQ equivalents, explains backoff differences, and presents the listed migration benefits and local workflow.