Update README with wildcard queue behavior details

Clarify behavior of wildcards in queue configuration

Author: bonniesimon

README.md

@@ -258,6 +258,8 @@ Here's an overview of the different options:
   ```
 
   This will create a worker fetching jobs from all queues starting with `staging`. The wildcard `*` is only allowed on its own or at the end of a queue name; you can't specify queue names such as `*_some_queue`. These will be ignored.
+  
+  Also, if a wildcard (*) is included alongside explicit queue names, for example: `queues: [default, backend, *]`, then it would behave like `queues: *`
 
   Finally, you can combine prefixes with exact names, like `[ staging*, background ]`, and the behaviour with respect to order will be the same as with only exact names.
 
@@ -340,20 +342,6 @@ instead of this:
 queues: back*
 ```
 
-Also, if a wildcard (*) is included alongside explicit queue names, Solid Queue treats the configuration as queues: *.
-
-This means that when * appears alongside explicit queue names, the worker uses the unfiltered polling query, ignores the specified queue order, and processes jobs from all queues.
-
-For example, this:
-```yml
-queues: [default, backend, incineration, *]
-```
-
-behaves the same as:
-```yml
-queues: *
-```
-
 ### Threads, processes, and signals
 
 Workers in Solid Queue use a thread pool to run work in multiple threads, configurable via the `threads` parameter above. Besides this, parallelism can be achieved via multiple processes on one machine (configurable via different workers or the `processes` parameter above) or by horizontal scaling.