feat: add prune command to remove dangling overlay links

[lollipop-onl]

Problem

apply only ever creates or repoints symlinks — it never removes one.
When a file is deleted from an overlay entry after apply has already
linked it into one or more checkouts, the symlink it created becomes a
dangling ghostq-managed link: it still points into this repo's
overlay entry, but the target no longer exists. Nothing in the CLI
could clean these up.

Approach

pruneFiles (in src/apply.ts, following the "modules return data,
index.ts prints" convention) walks the checkout tree directly,
skipping .git, rather than the overlay entry — collectEntryFiles
can't help here since the overlay file behind a dangling link is, by
definition, already gone. For every symlink it finds, it checks two
things:

1. does the target resolve inside this repo's overlay entry dir
   (resolve(target).startsWith(resolve(ctx.entryDir) + "/")) — i.e.
   is it ghostq-managed?
2. is the target actually missing on disk — i.e. is it dangling?

Only links satisfying both are removed, and only after an additional
git check-ignore gate (mirroring apply's own gating) confirms the
path isn't committed. After removing a dangling link, prune
opportunistically walks up removing now-empty parent directories, but
stops as soon as it hits a directory that still has other entries, and
never goes above the repo root.

Wired up as ghostq prune [path], added to USAGE in src/index.ts
and to the usage block / a new safety note in README.md.

Safety guarantees

• A link whose target still exists (a live overlay link) is never
  touched — that's apply's job, not prune's.
• Non-symlink files and symlinks pointing outside the overlay entry
  (user data) are never touched.
• A directory is only removed if it became empty as a direct result of
  pruning; directories with other entries are left alone.
• Idempotent: a second run after pruning is a no-op.

Test plan

• bun test — 42 pass, including a new test/prune.test.ts file
  covering: dangling link removal, live links left untouched, real
  user files / symlinks-to-outside left untouched, empty-directory
  cleanup vs. non-empty directories, and idempotency.
• bun run typecheck — clean.
• Manually exercised ghostq apply → delete overlay file → ghostq prune → re-run prune against a scratch repo; confirmed the
  dangling link is removed and the second run is a no-op.

🤖 Generated with Claude Code

https://claude.ai/code/session_013mAzjNvVWGBJT81cfTSJJN