feat(server): add an opt-in bypass for the multi-worker in-memory queue guard (#14658)

`ensure_multi_worker_safe()` refuses to boot the Gunicorn path when
`workers > 1` and `LANGFLOW_JOB_QUEUE_TYPE != redis`, because the v1
`/build` queues are process-local. That is the right default, but it also
blocks headless deployments that only drive Langflow through the API and
want multi-worker throughput without standing up Redis.

Add `LANGFLOW_DANGEROUSLY_ALLOW_MULTI_WORKER_WITHOUT_SHARED_QUEUE`
(boolean, default `false`). When set, the guard logs a loud warning and
returns instead of raising. Redis still short-circuits first, so a
correctly configured deployment never sees the warning even if the flag
is left set in its environment.

The warning names both hard breakages (the v1 `/build` editor and
playground, MCP over SSE — use Streamable HTTP) and the four subsystems
that silently degrade to per-worker or per-node: background-run reattach
latency, in-memory rate-limit counters, the node-local orphan-sweep file
lock, and webhook UI feedback. The reattach interval is read from
`_DURABLE_POLL_INTERVAL_S` rather than restated so it cannot drift.

`set_event_delivery` is deliberately unchanged: the queue is still
worker-local under the flag, so forcing `direct` delivery remains
correct. A test pins that the flag does not leak into that validator.

The refusal message now also names the flag so headless operators can
find the escape hatch without reading source.