fix(lock): release flock when Ctrl+C orphans docker children

The flock run-lock is held against the open file description, and bash
sets no close-on-exec on the {_LOCK_FD} redirection fd. Every docker/
compose child and every &-spawned parallel worker therefore inherits the
fd and keeps the lock held until its own copy closes. A Ctrl+C during
`docker compose pull` could orphan a docker subprocess (the signal
handler's `pkill -P` reaches only direct children, racily), and that
orphan kept the inherited fd — and thus the lock — alive, wedging every
later run with "Another hoist run holds the lock".

After acquiring the lock, hand the held fd to one childless holder
process and close our own copy so nothing we fork or exec afterwards can
pin the lock. `disown` keeps the holder out of the job table so the
parallel pool's `wait`/`wait -n` ignore it; the EXIT trap (also reached
via _on_signal's `exit` on INT/TERM) kills the holder, releasing the
lock the instant hoist truly exits — regardless of orphaned children.

Bump to v1.8.2.

Author: KingPin

CLAUDE.md

@@ -79,7 +79,7 @@ Each `process_container` invocation appends outcome tokens (`updated`, `update_f
 
 ### Run lock and exit code
 
-`_acquire_run_lock` (`hoist.sh:406`) takes an exclusive `flock` on `${CACHE_LOCATION}/hoist.lock` at startup (with an `mkdir`-plus-stale-PID fallback when `flock` is absent). A second run that finds the lock held logs and exits 0 rather than racing over shared state; `--list`/`--status` skips the lock. After `print_summary`, hoist **exits non-zero** if any container produced `update_failed`, `unhealthy`, or `rollback_failed` (drives `Type=oneshot` systemd, cron `MAILTO`, CI). Boolean gates (`update`/`notify`/`rollback`/`healthcheck.wait`, `ROLLBACK_DEFAULT`) are routed through `_is_true`, which accepts `true|1|yes|on` case-insensitively.
+`_acquire_run_lock` (`hoist.sh:417`) takes an exclusive `flock` on `${CACHE_LOCATION}/hoist.lock` at startup (with an `mkdir`-plus-stale-PID fallback when `flock` is absent). A second run that finds the lock held logs and exits 0 rather than racing over shared state; `--list`/`--status` skips the lock. **flock fd handoff:** bash sets no close-on-exec on the `{_LOCK_FD}` redirection fd, so docker/compose children and `&`-spawned workers would otherwise inherit it and keep the lock held — a Ctrl+C that orphans a `docker compose pull` subprocess would wedge every later run with "Another hoist run holds the lock". So after acquiring, hoist hands the held fd to a single childless holder process (`( exec sleep … ) &`, `disown`ed so the parallel pool's `wait`/`wait -n` ignore it), closes its own copy of the fd, and arms an EXIT trap (also reached via `_on_signal`'s `exit`) that kills the holder — releasing the lock the instant hoist truly exits, regardless of orphaned docker children. After `print_summary`, hoist **exits non-zero** if any container produced `update_failed`, `unhealthy`, or `rollback_failed` (drives `Type=oneshot` systemd, cron `MAILTO`, CI). Boolean gates (`update`/`notify`/`rollback`/`healthcheck.wait`, `ROLLBACK_DEFAULT`) are routed through `_is_true`, which accepts `true|1|yes|on` case-insensitively.
 
 ### Self-update
 

hoist.sh

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-HOIST_VERSION="1.8.1"
+HOIST_VERSION="1.8.2"
 HOIST_REPO="KingPin/hoist"
 
 DOCKER_BINARY="${DOCKER_BINARY:-$(which docker)}"
@@ -427,6 +427,22 @@ _acquire_run_lock() {
             log "Another hoist run holds the lock ($lock); exiting."
             exit 0
         fi
+        # flock is held against the open file description, not this process, and
+        # bash does NOT set close-on-exec on {var}> fds — so every docker/compose
+        # child we exec and every &-spawned worker inherits _LOCK_FD and keeps the
+        # lock held until its own copy closes. A Ctrl+C mid-`docker compose pull`
+        # can orphan a docker subprocess that keeps the inherited fd open, wedging
+        # every later run with "Another hoist run holds the lock". Hand the held fd
+        # to one childless holder process, then close our copy so nothing we exec
+        # or fork afterwards can pin the lock. `disown` keeps the holder out of the
+        # job table (so the parallel pool's `wait`/`wait -n` ignore it); the EXIT
+        # trap — which also runs after _on_signal's `exit` on INT/TERM — kills the
+        # holder, releasing the lock the instant hoist truly exits.
+        ( exec sleep 2147483647 ) &
+        _LOCK_HOLDER=$!
+        disown
+        exec {_LOCK_FD}>&-
+        trap '[[ -n "${_LOCK_HOLDER:-}" ]] && kill "$_LOCK_HOLDER" 2>/dev/null' EXIT
         return 0
     fi
     # flock unavailable: atomic mkdir lock. mkdir fails if the dir exists, which