fix: clear empty version-cache lock when update fetch fails

[daniel3303]

Summary

The update-check code touches statusline-version-cache.json before calling the GitHub API as a stampede lock — so N concurrent status-line renders don't all fire the request in parallel. If the fetch fails (network blip, rate limit, 5-second timeout, or — as happened today — the first render that ran in the narrow window between deleting the cache and the release actually appearing on GitHub), the touched file stays on disk at zero bytes with a fresh mtime. The 24-hour TTL check then sees a "fresh" cache and suppresses every update check for a full day, even though no data was ever written.

Code changes

• statusline.sh:463-477 — After a failed curl, if the cache file is empty (! -s), rm -f it so the next render retries instead of waiting 24h.
• statusline.ps1:432-452 — Mirror fix: in the catch, if the cache file exists and has Length -eq 0, Remove-Item it.

Success path is unchanged; if the cache pre-existed with valid content and the fetch fails, the old content is kept and reused (stale-but-usable fallback), retrying on the normal 24h boundary.

How to test

1. Delete the cache file: rm /tmp/claude/statusline-version-cache.json (macOS/Linux) or the Windows equivalent under $env:TEMP\claude\.
2. Temporarily block the API (e.g. point to a bogus host in the script, or disconnect the network) and run the script once.
3. Confirm the cache file is not left behind as a zero-byte file.
4. Restore the API, run the script, confirm the cache fills normally and the Update available: … line surfaces when VERSION is behind the latest GitHub release.