Document adapter behavior with recurring tasks

At the moment it is not possible to use solid_queue for scheduling while enqueueing the scheduled job into a different adapter. This should, at least, be documented.

Author: julik

README.md

@@ -609,6 +609,8 @@ end
 
 It's possible to run multiple schedulers with the same `recurring_tasks` configuration, for example, if you have multiple servers for redundancy, and you run the `scheduler` in more than one of them. To avoid enqueuing duplicate tasks at the same time, an entry in a new `solid_queue_recurring_executions` table is created in the same transaction as the job is enqueued. This table has a unique index on `task_key` and `run_at`, ensuring only one entry per task per time will be created. This only works if you have `preserve_finished_jobs` set to `true` (the default), and the guarantee applies as long as you keep the jobs around.
 
+**Note**: It is possible to have different `queue_adapter` settings set for different ActiveJob::Base` subclasses. While solid_queue supports this feature, it will not be aware that a job which is scheduled has, indeed, been enqueued for execution - as Solid Queue only sees its own `jobs` table`. This means that recurring tasks which enqueue Active Job jobs will reinsert them into their respective queue adapters repeatedly, every time the recurring tasks are getting scheduled, which is almost certainly not something that is desired. As a rule of thumb: a job class set in a recurring task must be enqueued into Solid Queue and into Solid Queue only.
+
 **Note**: a single recurring schedule is supported, so you can have multiple schedulers using the same schedule, but not multiple schedulers using different configurations.
 
 Finally, it's possible to configure jobs that aren't handled by Solid Queue. That is, you can have a job like this in your app: