fix: delete zero-byte cache files on load instead of leaving stale locks

[jburos]

Summary

When a computation is interrupted mid-write (process kill, OOM, crash), the cache file is left as a zero-byte placeholder. get_cache_status returns :started for these files.

The current handling warns but leaves the file in place, which means subsequent recomputation attempts also fail — the zero-byte file acts as a permanent lock requiring manual deletion.

Relation to 5185bd5

Commit 5185bd5 ("retry after deserialization failure") handles corrupted non-empty files that fail to deserialize. This PR handles the complementary case: zero-byte files left by interrupted writes.

Case	5185bd5	This PR
Non-empty file, deserialization error	✅ delete + retry	—
Zero-byte file (:started status)	✗ warns, leaves file	✅ delete + retry

Together they cover both failure modes cleanly.

Change

# Before
cache_status == :started && @warn "Cache file $cache_path exists but has size 0.\nAssuming a previous run failed."
touch(cache_path)

# After
if cache_status == :started
    @warn "Cache file $cache_path exists but has size 0. Removing and recomputing."
    rm(cache_path)
end
touch(cache_path)

🤖 Generated with Claude Code

[nsiccha]

Hm, I had at some point added the more more verbose warnings and the error to figure out what exactly was going on. The issue was that in the dependency graph, it makes sense to cache expensive leaves - but if they are accessed via multiple paths, these paths don't synchronize. The way this is fixed now is by having a global per type+property locked dict of path=>locks which enforces synchronization - no more deserialization failures now.