v1.34

The label overlay survives a rebuilt host, and recovers from the index (#312)

On a filesystem that refuses xattrs (NFS), labels live in tags-overlay.json keyed by <device id>.<inode>. A rebuilt host mounts the same share under a new device id, so on its first index pass no entry matched, and overlayPrune, which treated "not seen" as "deleted", emptied the store. That is how a production deployment lost its labels on 2026-09-03 (host up 20:16, first deploy 20:35, overlay rewritten to an empty store at 20:35).

• Identity tolerates the device id: an entry whose recorded path still resolves to the same inode and creation time is the same file and is re-keyed to the live device id, both in reapplyTagOverlay and in the prune.
• A prune that recognizes nothing at all is refused, since a corpus does not vanish between two index passes; the file is copied to .bak before any entry is removed.
• The index still carries the label rows written from the overlay, so an empty overlay beside an index with labels is treated as a lost overlay: recoverOverlayFromIndex() adopts them at startup (20 s after boot) and on demand via POST /api/kb/tags/recover.

Three tests cover the host change (kept and re-keyed), a real deletion (pruned, backup written), and adoption. 106 pass.