fix(storage): stop compaction from destroying the log on Windows

[greit0n]

Fixes #377.

The problem

Store.Compact() deletes the live log, then renames the compacted copy into its place while
that copy is still open, discarding the results of both calls:

s.log = newLog          // newLog is still OPEN
...
_ = oldLog.Close()
_ = os.Remove(oldPath)              // original destroyed first
_ = os.Rename(newLogPath, oldPath)  // fails: source still open. Error discarded.
s.log.path = oldPath                // recorded as success regardless

Go opens files on Windows without FILE_SHARE_DELETE, so renaming a file the process itself still
holds open fails with a sharing violation. This isn't an occasional antivirus problem — on Windows
the rename fails every time, and because the original was removed one line earlier, every
compaction that runs there destroys the store.

The error is discarded and s.log.path is updated anyway, so the index ends up describing a log
that no longer exists. That surfaces as failed to read during compaction: EOF on every
subsequent 5-minute tick, forever, since nothing revisits the decision. openAppendLog uses
O_CREATE, so a restart silently recreates the log empty and throws away the data still
sitting in the .compact file.

The fix

• Close both logs before the swap — required on Windows for either path to be renameable.
• Drop the os.Remove. os.Rename replaces an existing destination on POSIX and Windows alike,
  so removing it first only created a window where a failed rename lost everything.
• Check the rename. On failure, reopen the untouched original so the store keeps serving the
  pre-compaction state, and return the error instead of reporting success.
• Retry the rename briefly. Antivirus, indexers and backup agents hold transient handles; the Go
  toolchain retries module-cache renames for exactly this reason (cmd/go: 'Access is denied' when renaming module cache directory [1.13 backport] golang/go#37802).
• Adopt an orphaned <name>.db.compact at startup when the log is missing or empty, so stores
  already broken by this bug recover their data instead of restarting empty.

Tests

Three new tests in pkg/storage/hybrid/store_compaction_test.go. Two of them fail on main on
Windows — including the plain success path, which is the point:

--- FAIL: TestCompactSucceedsAndLeavesNoTempFile
    compaction temp file must not be left behind
--- FAIL: TestRecoverOrphanedCompaction
    data must be recovered from the orphaned .compact file: key keeper: key not found

All three pass with this change, and the existing suite is unaffected (go test ./... green).

TestCompactKeepsLogWhenSwapFails forces an unrenameable destination by holding it open; it skips
on platforms where that rename legitimately succeeds, so it stays meaningful on Linux/macOS
without being flaky.

Notes for review

• Behaviour on POSIX is unchanged apart from the swap no longer being destructive and errors now
  being surfaced.
• The startup recovery only triggers when the main log is missing or header-only, so it can't
  shadow a healthy log. The .compact file is fully written and synced before any swap is
  attempted, and Compact() holds the store lock, so it is never a partial snapshot.
• Running in production on Windows since 2026-08-03. On first start with the patched binary the
  previously orphaned queue.db and repair_runs.db were adopted and are now normal .db files
  again.

🤖 Generated with Claude Code