awa: investigate non-monotonic throughput dip at 256 workers

The 2026-05-01 awa-extended-scaling run
([`results/2026-05-01-awa-extended-scaling/`](https://github.com/hardbyte/postgresql-job-queue-benchmarking/tree/main/results/2026-05-01-awa-extended-scaling))
shows a real non-monotonic dip:

| workers | throughput |
|---:|---:|
| 128 | 6,481 |
| **256** | **4,800** |
| 512 | 5,344 |
| 1,024 | 7,837 |

Each point is a 75 s clean phase median over ~15 samples — well above
measurement noise. The dip is reproducible.

Two plausible causes:

- **Connection-pool saturation around 256.** awa's claim path holds
a connection per active worker; postgres `max_connections=400` is
only ~1.5× the worker count, so contention on connection acquire
goes up sharply right around here.
- **`LWLock` / `Lock` contention** on the queue ring metadata at
some specific concurrency, transitioning back to no-contention
once workers fan out past the cliff.

Both are testable with the wait-event sampler that's about to land
(see #?). Re-running with that instrumentation will surface whether
256 sits on a `LWLock` cliff or a connection-acquire wait, and
whether bumping `max_connections` or pool size shifts the dip
location.

Not a blocker — peak throughput at 1,024 is still the highest in the
run — but worth understanding before publishing "awa scales linearly"
as a claim.

Bắt đầu bằng cách kiểm tra results/2026-05-01-awa-extended-scaling/ và cấu hình benchmark cho lần chạy với 256 worker. Chạy lại workload bằng wait-event sampler được đề cập trong issue, sau đó so sánh các lần chờ connection-acquire và LWLock/Lock giữa các số lượng worker. Hoàn tất nghĩa là xác định nguyên nhân có khả năng xảy ra và kiểm tra xem việc thay đổi max_connections hoặc kích thước pool có làm thay đổi vị trí của mức sụt giảm hay không.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.