WCS: cola de asignación de tareas en RabbitMQ

Sin consumer groups ni topics: exchange por defecto y un único consumidor por cola, creado a mano en @PostConstruct (prefetch 1, sin setAcknowledgeMode)
acknowledge-mode: manual y listener.retry del yml configuran la fábrica de Spring Boot, no este contenedor (inferido)
El listener hace basicAck tras asignar RGV, o si la tarea ya no existe o ya tiene RGV (descarta); sin RGV o con excepción, basicNack(requeue=true)
Tras cada mensaje, con ack o nack, espera 2 s fijos: cada cola procesa como mucho ~1 mensaje cada 2 s; el reintento no tiene límite

Exchange por defecto; routing key = nombre de cola; cuerpo = taskId en texto
Prioridad AMQP = p>100 ? p/100 + p%100 : p (x-max-priority 255)
RabbitTemplate con retry 3 intentos cada 3 s; publisher-confirm correlated activo, pero no se registra ConfirmCallback

Ningún JAR declara x-dead-letter-exchange, TTL ni ConfirmCallback: no existe DLQ; lo no enrutable solo se registra en log
Orden solo dentro de cada cola (prioridad + un consumidor); no hay orden global entre colas
Una tarea que nunca encuentra RGV vuelve a la cola sin fin y puede retrasar a las demás de su cola (inferido)
TRANSFER: el aviso por groupId deja tip y notificación, pero igual intenta asignar
Productores, colas y consumidor viven en el mismo proceso suray-server-service; las colas se declaran solo al arrancar

rabbitmq/RabbitMQConfig, ProducerService, MyMessageListener, CommonConfig
Liberan tareas: PlcTaskThread (CALL_RGV), LifterTaskManage.assignRgv, RgvTaskHandleImpl.afterRgvArrivedEnd
thread/AssignTaskThread (re-encola tareas NEW/WAIT/AVOID de un RGV caído o sin batería)
TaskDBServiceImpl.insertTask y updateIsAllowAssignmentRgv
back/application.yml:24-50; notas 04-paso4 §2-3, 02-paso2b §3-4, 05-paso4b
Sin git: las referencias no están fijadas a una revisión