v0.9.5

• The index cleans up after itself. An upgrade's rebuild left its old
  rows' space free inside the file (a 229 MB store stayed 229 MB holding
  75 MB), and each release left a stale tree snapshot for every checkout
  not queried since; only trekr --gc --vacuum, which nothing mentioned,
  gave them back. Now, after an index pass — the one a query or the editor
  starts, or trekr --index — trekr measures the waste at most every two
  hours, and when it is at least 32 MB and a quarter of the file, a
  background process removes the stale snapshots, collects the blobs only
  a query read a week ago, and gives the free space back to the disk a few
  megabytes at a time, so an index or edit waits a fraction of a second,
  not for the whole compaction. A store from before this release is
  rewritten once instead (through a temporary file, when the disk has room
  for twice its live size), which switches it. It never runs on a query,
  waits for nothing, and skips a store another trekr is writing. Nothing
  to do: a store 0.9.4 rebuilt shrinks after its next index.
• --gc collecting many checkouts is ~35× faster. Each blob it
  deleted scanned a table of class-body calls: removing 240 checkouts from
  a 1 GB index took 34 minutes, and takes 56 s now. An existing index gains
  the missing index in the background, or at the start of the next --gc
  — a dry run included, which says so (indexes) and removes nothing;
  nothing is rebuilt.
• --status says how big the index is and what it could give back
  (storage in --json), when the background cleanup last ran, and why
  it left space it meant to give back (no_room: the disk lacks room to
  rewrite the index once).
• --gc's reclaimed_bytes is what left the disk — the snapshots,
  copies and stores it removed, and the file's shrink after --vacuum. It
  said 0 after removing snapshots, since it counted only the pages freed
  inside the file; those are freed_bytes now, and free_bytes is what is
  left free.
• A question that indexes its checkout first no longer sometimes builds
  the tree twice. When the index it started finished its rows before the
  query's first look, the query stopped waiting for it and assembled the
  tree itself while the index prepared the same one.
• Hover at a constant's definition in class Object names it OBJC,
  as hover at a mention already did; it said Object::OBJC.