Apply producer in-flight tracking to poller-based adapters before next cross-system sweep

## Context

PR #30 fixed an overshoot in awa-bench's depth-target producer: the
producer now tracks its own contribution since the last depth-poll
snapshot, so bursts during the ~200 ms stale window self-limit.

## Per-adapter shape

| Adapter | Depth source | Status |
|---|---|---|
| pgboss | live \`getQueueStats()\` inside producer loop | accurate (already tracks target) |
| pgmq | live \`queue_depth()\` inside producer loop | accurate (already tracks target) |
| **awa** | atomic + in-flight tracker (this fix) | accurate |
| oban | ETS table populated by 200 ms-cadence poller | **overshoots** |
| river | atomic populated by 200 ms-cadence poller | **overshoots** |
| pgque | variable populated by 200 ms-cadence poller | **overshoots** |
| absurd | variable populated by 200 ms-cadence poller | **overshoots** |
| procrastinate | variable populated by 200 ms-cadence poller | **overshoots** |

## Why it matters

At a given \`target_depth\` setting, the five overshoot-adapters end up
operating at higher effective backlog than the three accurate-adapters.
Higher backlog means more queued work, more scan cost on claim
queries, and (depending on the system) more lock contention or
table bloat. Cross-system throughput comparisons under depth-target
mode are not at the same operating point.

The pattern from PR #30 applies cleanly to all five poller-based
adapters:

1. Snapshot \`enqueued\` in the poller right after updating
\`queue_depth\`, keyed against a consistent moment.
2. In the producer, compute \`effective_depth = queue_depth +
(enqueued_now - enqueued_at_poll)\` and throttle against that.

## Acceptance criteria

- oban, river, pgque, absurd, procrastinate producers all track
target accurately under depth-target mode (median \`queue_depth\`
within ±20 % of target during steady-state soak).
- Each adapter's change is a self-contained PR with its own smoke
showing the before/after delta on the same hardware.
- Documented in CONTRIBUTING_ADAPTERS.md so future adapters get
the pattern right from the start.

## Out of scope

- The 200 ms cadence itself. PR #30's earlier commit established
that 200 ms is load-bearing for the depth-target controller;
loosening it regressed throughput by ~17 % and doubled depth.
The fix is the in-flight tracker, not a tighter poll.

Refs: PR #30, awa #289 (queue_counts_fast — the other half of the
depth-target hot path).

まず PR #30 を確認して既存の in-flight tracking パターンを理解し、次に oban、river、pgque、absurd、procrastinate の poller と producer のパスを特定します。depth-target の動作を同一ハードウェアでの smoke 実行と比較し、定常状態のキュー深度が受け入れ範囲内にあることを検証して、アダプターパターンを CONTRIBUTING_ADAPTERS.md に記録します。

索引モデルが issue の本文から書いたものです。