TestFS 0.1.19

What's new in 0.1.19

A re-release of 0.1.18's contents with the build-number monotonic-
ity bug fixed, so Sparkle actually offers the update.

Fix

• .build_number on main had been stuck at 89 since 0.1.14 —
  every release.sh run bumped it to 90 in the archive but never
  committed the new value back, so consecutive releases shared a
  CFBundleVersion. Locally-iterated builds (e.g. the in-the-wild
  0.1.15 at build 94) ended up with a higher build number than
  any subsequently published release. Sparkle's "newer build wins"
  logic then refused every "update" as a downgrade. .build_number
  bumped to 100 so this 0.1.19 archive lands at 101, above the
  affected installs.

Carried from 0.1.18

• Sparkle pre-install hook gates updates on a clean unmount:
  active testfs mounts no longer pin the FSKit appex into a half-
  applied install. On any unmount failure the install is aborted
  loudly via an alert, leaving the user on the previous version
  with a clear message instead of a silently-stale bundle (#65).

Auto-update

Existing 0.1.15+ installs should now correctly detect this update
via Sparkle within ~24h or immediately via App ▸ Check for Updates….
Updates into 0.1.19 use the pre-hook flow — unmount any active
testfs volumes before accepting the prompt this one time.

Tracked follow-up

• release.sh will be hardened to commit .build_number along with
  appcast.xml so the baseline on main stays current after every
  release, preventing this regression class.