## Problem/Motivation - A Cloudflare queue's retry limit (`max_retries`) and dead-letter queue are settings of its **consumer**, not of the queue. The suite has no way to set them: the Queue primitive creates and records the queue only, and `cloudflare_queue` 1.0.0-alpha3 creates a bare HTTP pull consumer with Cloudflare's defaults and no dead-letter queue. - Without a dead-letter queue, Cloudflare deletes a message once it has used up its retries. - Settings applied once at creation drift. They need to be desired state, reconciled whenever they differ, like the rest of the suite's provisioned assets. - The consumer is the queue's control plane, so it belongs to this module, not to the `cloudflare_queue` backend (the data plane). ## Proposed resolution - The queue asset gains a `pull_consumer` mapping: `reconcile` (whether the suite manages the consumer), `max_retries` (0 to 100) and `dead_letter_queue` (a Cloudflare queue name). - Every save of a queue asset that reconciles its consumer makes Cloudflare match. That covers the form, a configuration import, a programmatic save and provisioning. The save creates the consumer if the queue has none and updates it if it differs, sending the consumer's other settings back unchanged, because Cloudflare's update replaces the whole consumer. It never deletes a consumer and never replaces a Worker consumer. - Reconciling uses the asset as `settings.php` overrides it. `$settings['cloudflare']['compute']['reconcile_consumers'] = FALSE` turns it off for an environment that imports another's configuration but does not own its queues. - The outcome is shown, logged and recorded. A status report row reads the recorded results (no network), and a new queue detail page shows the desired settings beside the live consumer, with any drift. A save with reconciliation switched off clears the recorded result, so the row never reports settings that were not sent. - The queue form prefills from the live consumer when it is not yet reconciled, so ticking the box keeps settings made elsewhere. - Provisioning: a queue spec can ask for an HTTP pull consumer, which is created when the queue has none. - A queue asset now depends on its credential set (so a configuration import creates the set first). - `retry_delay` is not managed: Cloudflare stores it on an HTTP pull consumer but does not apply it. - A queue list that cannot be read (an unresolvable account, a transport or API error) is reported as that, not as a missing queue, by reconciling, the provider's status and provisioning. - Fixes saving the queue form, which blanked the recorded queue id. - Requires Drupal 11.2 or later. ## API changes - New: `PullConsumer` (value object, also the spec shape: `QueueProvider::SPEC_PULL_CONSUMER`), `QueueConsumerManagerInterface`/`QueueConsumerManager`, `QueueConsumerState`, `QueueConsumerStatus`, `QueueConsumerResult`, `QueueDetailController`. - `QueueInterface` gains `getPullConsumer()` and `setPullConsumer()`. - `QueueProvider` and `QueueAssetKind` take the consumer manager. - `QueueCatalogInterface::findByName()` returns `error` as well: why the queue list could not be read, or NULL. Callers are unaffected; an implementation of the interface must now return it. An account that cannot be resolved is now an error, not `forbidden`. ## Data model changes - `cloudflare_compute.queue.*` gains `pull_consumer`. A post update adds it to existing queue assets with reconciling off, so it makes no Cloudflare call and leaves existing consumers as they are. The re-save also records the credential-set dependency. It re-saves the assets override-free, so `settings.php` overrides are not written into active configuration.