Batch-apply the given proposal ids in ONE transaction. Any 409 needs_rebase (or a mid-batch failure) rolls the whole batch back so a partial apply can never leave the queue inconsistent.

Applies in id ASC (staging) order regardless of the order ids were submitted in. A single dream pass can stage an add for a brand-new slug followed by an update against that same in-pass slug (see the same-pass slug reservation in memory_consolidate.py's _run) — the update's target only exists once the add is applied first, and staging always assigns the add a lower id (later batches see earlier batches' reservations, never the reverse). Trusting the client's array order instead let a UI that lists proposals update-before-add send that pair reversed, 409 on the very first item, and roll back the WHOLE batch — so "approve all" could never succeed even though every individual proposal was independently applicable in the right order.