epic: the adoption story is still Celery-shaped

Why

The only migration guide is Celery, and the only comparison table is against Celery. That was
the right framing for a Python library. It is the wrong framing for what 2.0 is.

The things FlexiQ now competes with are not all Python and not all libraries. Temporal is
the other durable-execution engine with workflows and durable steps. Cloud Tasks and
EventBridge are what a team on a managed platform uses instead of running a queue at all,
and they are the natural on-ramp for the push executor (#849) — someone already POSTing to an
HTTP endpoint per task is already running the topology FlexiQ would give them. BullMQ is the
incumbent for the Node SDK, and there is no guide for the users that SDK was built to win.

A comparison table that only mentions Celery reads as a Python library that grew, which
undersells the engine and misroutes everyone else.

Shape

• migration guides for BullMQ, Cloud Tasks / EventBridge, and Sidekiq once a Ruby client exists
• a comparison table that includes Temporal and Cloud Tasks
• a hosted demo, so evaluating does not require installing

What this is not

Not competitive marketing. The existing Celery comparison is credible because it is fair.
Every row added here has to survive being read by someone who uses the other tool daily —
including the rows FlexiQ loses.

Not a guide per framework. Migration guides are per queue being replaced, which is what
docs/content/docs/java/ already does for the queue it displaces.

Start by reading the existing Celery migration guide and comparison table, then inspect docs/content/docs/java/ to understand the current guide structure. Define the BullMQ, Cloud Tasks/EventBridge, and Sidekiq guide scope, expand the comparison to Temporal and Cloud Tasks, and document what the hosted demo must provide. Done means the guides, fair comparison, and evaluation demo are all specified or implemented without unsupported claims.