Function release_held 

pub async fn release_held(
    pool: &PgPool,
    actor: &Actor,
    holder: Uuid,
    project: Option<Uuid>,
) -> AppResult<Vec<CheckInOutcome>>

Releases the check-outs holder still has – in every group, or only in project – for a leaver (issue #173). Each release goes through revisions::cancel_checkout in its own transaction, so the permission rule stays in one place, every release is audited (revision.checkout_forced_release) and one refusal does not stop the others; the outcome lists every revision.

Invariants

• Permission: CAD editor. Administrators release in every group they can read; anyone else needs to manage project (“not found” for a hidden group, 403 otherwise) or, without project, at least one group (403), and only check-outs in the groups they manage are considered. Per revision cancel_checkout decides: a manager only releases the locks of users who are no longer members or are deactivated; the rest are listed as refused (an active member’s lock needs a reason, one at a time).
• Visibility: revisions the actor may not read are left out, as if they did not exist (a need-to-know group with admin_read = none hides its revisions from administrators too).
• Bounds: at most MAX_RELEASE revisions per run.
• Audit / notifications: those of cancel_checkout, per revision.
• Atomic: one transaction per revision.