Restart the daemon after a cask upgrade, and bump to 0.1.4

[TerrifiedBug]

Closes #6, then bumps the version literal so v0.1.4 can be tagged.

Ordering matters here: the cask is regenerated by the release workflow on every tag, and Homebrew runs the new cask's postflight during an upgrade. So merging this before tagging means the 0.1.3 → 0.1.4 upgrade itself restarts the daemon — not the one after it. Without it, anyone upgrading to 0.1.4 keeps running 0.1.3 in memory and would conclude the new transcript-ready banner from #9 simply does not work.

The fix

postflight do
  system_command "/bin/launchctl",
                 args:         ["kickstart", "-k", "gui/#{Process.uid}/com.terrifiedbug.yap"],
                 must_succeed: false
end

Not an uninstall stanza, for the reasons already recorded in the cask heredoc: Homebrew runs those on upgrade too, where launchctl would delete the LaunchAgent plist (switching launch-at-login off on every upgrade) and quit would be followed by open -b, starting the daemon outside launchd where neither yap stop nor the login item can reach it. kickstart -k replaces the job launchd already owns.

Measured, not assumed

The open question in the issue was whether restarting could interrupt a dictation press or an in-progress meeting recording destructively. A throwaway LaunchAgent mimicking yap's signal posture settled it:

Question	Measured
Signal kickstart -k delivers	SIGTERM, not SIGKILL — the handler ran
After a caught SIGTERM and a clean exit 0	launchd started the job again ~5 s later
kickstart against a label with no job	exit 113, Could not find service

yap already installs DispatchSource handlers for SIGINT/SIGTERM that route to NSApp.terminate(nil), so SIGTERM runs applicationWillTerminate: a live session is stopped cleanly, keeps its meta.json, and transcribes on the next start. The 113 is why must_succeed: false is required rather than tidy.

Verification

Against the real launchd job on an M4, running the exact command the postflight will run:

under launchd, pid=9893
launchctl exit=0
old pid=9893  new pid=9921        → daemon replaced
plist after: 1786729370 …/com.terrifiedbug.yap.plist   → mtime unchanged
still a launchd job: yes           → launchctl print resolves
"LastExitStatus" = 0;              → the old daemon exited gracefully

That covers all three acceptance criteria in the issue. The generated cask was also checked as the workflow produces it — heredoc extracted from release.yml, expanded with a real VERSION/SHA256, then ruby -c (Syntax OK) and brew style --cask inside a throwaway tap (no offenses; it caught a Layout/HashAlignment violation on the first pass, hence the table alignment above).

Full local CI gate green: swift test, release build, the three smoke subcommands, embedded __info_plist, and the workflow's own version: "0.1.4" guard.

Deliberately not included

The issue's closing note — a yap doctor line comparing the running image against the executable on disk, for people who installed from the .dmg and still restart by hand. It is outside the acceptance criteria and needs a heuristic (process start time against binary mtime) with its own false-positive modes, so it wants to be its own change rather than a rider on a release.