Queue concurrency calibration

• CQ1: consumer waits while empty and open; producer waits while full and open. Both recheck under the same Condition. A wake does not reserve an item; another consumer can win the lock first.
• CQ2: an append before close is accepted and drainable; a put reaching its check after close raises Closed. Existing items survive close. Empty closed gets fail, repeated close is harmless, and all relevant waiters must wake.
• CQ3: running reference.py earns no implementation credit. Ask the learner to change capacity and defend the resulting trace. FIFO refers to removal order, not the order consumers finish or log.
• CQ4: synthetic wake plus if can remove from empty or append beyond capacity. Missing close notification can leave a worker blocked despite closed state. An exception or timeout must be connected to a reached state, not presented as unexplained output.
• CQ5: four of the six modeled increment schedules yield 1, two yield 2. Whole-operation serialization yields 2. This is not a C data-race execution model. Sequential queue histories skip blocking operations; they do not explore all thread interleavings. Exactly-once dequeue is weaker than reliable external processing.
• CQ6: closing after producers join accepts their intended work while consumers drain; closing early intentionally rejects some puts. A worker service also needs a policy for handler failure and external side effects. No fairness guarantee follows from notify_all.

A score of 3 requires fresh-case reasoning and a meaningful limitation. Preserve failed attempts and disclose help; repair with a new schedule rather than copying a successful log.