SchematicClipboardCache

Keeps parsed schematics in memory so a content reload does not re-parse files that did not change.

/betterstructures reload exists to pick up edited configuration, and config.yml is not part of the schematic set — but every reload used to re-read and re-convert every .schem anyway. On a full content install that is 681 files, and acceptance runs measured ~8s of the ~15s reload going into nothing but producing clipboards byte-identical to the ones already in memory.

A file is considered unchanged when its path, size, last-modified timestamp, and content digest all match what they were when it was parsed. Timestamps come from BasicFileAttributes rather than lastModified so they carry the full resolution the filesystem records (100ns on NTFS) instead of being truncated to milliseconds, which closes the window where a file could be rewritten to the same size within the same millisecond and still look unchanged.

Deleting a schematic is handled by retainOnly: the caller re-walks the folder every reload and only files it actually found stay cached. Adding one is a plain miss, because nothing was ever cached under its path.

Nothing here is a source of truth. Every lookup that cannot be proven current is a miss and falls through to a real read, so the worst a stale or unreadable entry can do is cost the reload the time it used to spend anyway.