docs: a Sidekiq migration guide, once a Ruby client exists

Sidekiq is the incumbent in Ruby, and Ruby is the language the remote SDK tier makes cheap to
support (#834).

The guide is straightforward if the client exists and pointless if it does not, so this is
explicitly blocked on #834 and should stay closed-as-blocked until then.

When it is unblocked:

• perform_async / perform_in / perform_at → enqueue, delayed enqueue
• sidekiq_options — queue, retry, backtrace, dead — → the options surface
• the Sidekiq Web UI → the FlexiQ dashboard
• the retry set and the dead set → retries and the dead-letter queue, which is inspectable and
  replayable
• unique jobs (the enterprise feature, or sidekiq-unique-jobs) → unique_key and idempotency,
  which are in the core rather than a plugin

The honest delta matters more here than in the other guides. A Ruby client is producer-side
only: it enqueues, it does not execute. A Sidekiq user replacing Sidekiq needs workers, and
until the executor door has a Ruby implementation the answer is that the workers run in another
language. Say that at the top of the page, not at the bottom.

This guide is explicitly blocked on issue #834, so first confirm that a Ruby client exists before starting. Then use the listed Sidekiq-to-FlexiQ mappings as the outline, and make the producer-only limitation and non-Ruby worker requirement prominent; the guide is done when those differences and the dashboard, retry, dead-letter, uniqueness, and scheduling equivalents are documented.