fix(managed-agent): ≥8 concurrent Turns stall after the model answers on modest hardware (lock convoy in the store path)

What happened?

Found by bisection with the new --list-pagination mode of
scripts/run-managed-agent-server-e2e.ts (full packaged stack), varying the
number of Sessions created at once on the same tenant:

The stall shape on the rig, twice deterministically:

• all 8 Sessions admitted, all 8 Turns reach turn.started;
• all 8 model requests reach the (fake) provider and are answered instantly —
  so the model call is not the bottleneck;
• zero message.delta/completion commits follow: the pipeline between
  "model answered" and "journal commit" produces nothing for 120+ s;
• the coordinator logs Managed Turn lease renewal failed … failure=CannotAcquireLockException on the -dispatch-lease thread (3×).

So the Turns don't fail and don't finish — they wedge the same way
#13322 records for a held model stream, here triggered purely by concurrency.

What did you expect to happen?

N concurrent Turns may be slower, but they must keep making progress and
settle; a lock in the store/dispatch path must not convoy every writer
behind one another until the InnoDB lock wait times out. If the intended
shape is a concurrency cap, the admission should queue Turns explicitly
instead of starting all of them into a stall.

Client information

Packaged-stack E2E runner (--list-pagination, twelve Sessions), repo HEAD
1cf80d46d0. Rig: Orange Pi 5 (8× Cortex-A76/A55, 16 GB), Ubuntu 22.04,
MySQL 8.0.45, JDK 21. Compare: the same 12-Turn burst passes on macOS arm64
in ~35 s.

Anything else we need to know?

Parent: #12380 / Stage G (#12952). Same-wedge family: #13322 (held stream),
#13327 (coordinator-only crash). The CannotAcquireLockException on dispatch
lease renewal is the only diagnostic surfaced; it may be a symptom (a Turn's
commit transaction holding the row the renewal wants) rather than the cause.