taskguard v0.9.0

Added

• taskguard top: the Queue view is a tree. The jobs of one task-runner
  run sit under one row, named by the command that started it, with their
  counts, CPU and memory. The taskguard calls running inside a job, such as a
  dev stack's start-up builds, show under that job with their own CPU and
  memory. ← folds a row, → unfolds it, and Enter on a run's row does
  both. Running jobs keep their place,
  oldest first.
• --wraps: a command that runs other taskguard jobs runs straight through
  from its first run, and the jobs inside it queue on their own. A queued run
  that had jobs inside it prints advice to pass it.
• The Config view of taskguard top lists warn_admit.

Changed

• A command that wraps other taskguard jobs, such as taskguard bun run ci:local around a turbo run, runs straight through from its second run on,
  and the jobs inside it queue on their own. Queued as one job, it booked its
  biggest run, up to 20 GB, also when turbo's cache left almost nothing to do;
  on one machine such wrappers waited 995 minutes in 17 days. A long-lived
  job, a job in a pool, and a job with a minimum stay queued.
  taskguard prune 'KEY' --apply queues the command again. (#24)
• A run starved of memory raises the next run's need by 25% only when it
  reached 90% of its need. One starved far below its need was squeezed by
  other programs, and the extra room went unused. (#24)
• macOS: the kernel's memory warning level no longer stops every new job.
  At warning, jobs start while memory fits without any leeway, and not while
  a first run still grows (at most two minutes). A dev stack kept the level
  at warning with half of memory free, and the browser proof that needed the
  stack waited behind it for up to an hour. Critical still stops every new
  job. warn_admit = false brings back the old rule. (#22)

Prebuilt binaries for macOS (Apple silicon, Intel) and Linux (x86_64, ARM, static musl). Each archive holds the taskguard binary; a .sha256 file sits next to it.