M13 — choose the Messenger buses where the middleware is installed

[gplanchat]

The bundle's middleware went in at the head of every Messenger bus in the application, with no way out.

What was not at fault

Two things the pass does that stay, because they are right:

• Being at the head. A lock must wrap what follows, doctrine_transaction included — releasing it before the commit would reopen the window it closes.
• Going through a compiler pass. Symfony has no messenger.middleware tag: nothing calls findTaggedServiceIds() on it, and a service carrying it would be defined and never installed, silently. The pass's docblock already documented this, and history bears it out — that is exactly what had happened to the resume lock.

The defect is the scope, and nothing else.

What it cost

The DBAL resume lock takes a lock per execution, and the profiling middleware measures. Installing them on an application's business command bus — which carries no durable message — is work and a contention point nobody asked for, on a bus whose author does not even know Durable is in the stack.

The fix

durable:
    messenger:
        buses:
            - messenger.bus.durable

The default remains every bus, deliberately: the bundle does not know which bus the application routes ResumeWorkflowMessage to. Narrowing it on our own initiative would remove the lock from the bus actually carrying the work — a silent loss of durability, precisely what that lock exists to prevent. No application is affected without asking for it.

An unknown identifier is refused at compile time, with the list of declared buses:

durable.messenger.buses names "messenger.bus.typo", which is not a Messenger bus of this application. Declared buses: messenger.bus.durable. A bus identifier is a service identifier — "messenger.bus.default" for FrameworkBundle's default bus.

Letting the typo through would have produced the very silence we are trying to remove: the configuration looks set, nothing gets installed. That is the failing the audit points at everywhere else in this bundle.

Three cases

Case	What it keeps
no configuration, two buses	both are served — regression net, and it already passed before the fix
a list of one bus, two buses declared	only the named one is served
a list naming a non-existent bus	refused at compile time, message naming the culprit

Coordination with #277

The cases go into a new file rather than into DurableMiddlewareReachesTheBusTest, which #277 already modifies — no point adding a conflict. And my test's container places lock.factory, whose check #277 introduces, so that merging the two goes smoothly whatever the order.

Verification

	main	this branch
unit suite	1073 tests, 4 errors	1076 tests, 4 errors
PHPStan	2 errors	2 errors

Pre-existing and identical errors (illuminate/cache missing on this machine).

The configuration reference carries the new node, in both languages, with the reason for the default rather than just the syntax.