bug: concurrent slot admission can exceed configured capacity #3305

Problem

On official dev a72271d, SlotService.acquire_slot checks ZCARD and then writes ZADD separately. Two backend workers can both observe available capacity and both return True, authorizing more dispatches than max_parallel_tasks.

A repeated execution ID also returns True when spare capacity exists and overwrites the original slot metadata. Callers interpret True as permission to start work, so it is not a safe idempotent receipt.

Reproduction

Use an empty disposable Redis7 database and six independent Python processes calling the unmodified SlotService for the same agent. A barrier immediately after each first real ZCARD read forces a valid interleaving. With capacity1, all six calls return True and six members remain. With capacity3, all six still succeed. Using the same execution ID, all six calls return True (one ZSET member, six dispatch authorizations). No model or live agent is required.

Always-on regression tests also reproduce the contention with independent fakeredis clients; a sequential duplicate test reproduces metadata replacement.

Expected

At most the configured number of new admissions may succeed. An already-held execution ID must not authorize another dispatch or replace its metadata. Failed/ambiguous Redis transactions must not return dispatch authorization.

Scope

A focused WATCH/MULTI/EXEC correction and regression tests have been prepared and independently reviewed. This addresses atomic admission only; stale-slot cleanup, runtime termination and uncertain-outcome recovery are separate lifecycle boundaries. Related background: #98 and #1081. Searches for capacity race and ZCARD did not find a direct open duplicate.