Move history persistence's fsync off the collector's tick goroutine

[LarsLaskowski]

📖 Description

persistHistory() ran synchronously inside Run's select loop: encoding
and atomically writing (with fsync) the history file blocked fastTick
from running for the whole duration of every write — once per slowTick
and once more on shutdown. time.Ticker drops rather than queues missed
ticks, so a slow write (e.g. an SD-card fsync stall under
updates_check_minutes-driven writes, or while the root-privileged apt
timer is doing I/O) silently dropped fast-tick samples instead of merely
delaying them.

The snapshot (c.History()) is still taken on the caller's goroutine so it
stays a consistent point-in-time view, but the encode-and-write now runs in
a background goroutine tracked by a new Collector.persistWG
(sync.WaitGroup). A buffered try-lock (Collector.persisting, capacity 1)
skips — rather than queues — an overlapping flush while a previous write is
still in flight, since the next flush writes newer data anyway. Run's
ctx.Done() branch now calls persistWG.Wait() after the final
persistHistory(), so the last flush is still guaranteed to land before
Run returns; this remains bounded by cmd/pimonitor/main.go's existing
10s shutdown context (collDone vs. shutdownCtx.Done()), so a stuck
fsync still cannot hang the process.

Collector.writeFile is now a field (defaulting to writeFileAtomic) so
tests can substitute a controllable write function without touching real
disk I/O.

Not folded in (per the issue): fsyncing the parent directory after
os.Rename for full crash durability — a separate, minor concern.

🎫 Issues

Closes #110

👩‍💻 Reviewer Notes

Focus areas: the try-lock in persistHistory (internal/collector/persist.go)
and the shutdown join in Run (internal/collector/collector.go). Verified
only against fixtures/synthetic slow writes — no real Pi/SD-card hardware
was used to reproduce the fsync stall itself, per the issue's own caveat
that the stall durations are general platform knowledge rather than
measurements from this project.

📑 Test Plan

Added to internal/collector/persist_test.go, all driven by channels (no
time.Sleep-based synchronization) and run under -race:

• TestCollector_PersistHistory_DoesNotBlockOnSlowWrite — persistHistory()
  returns promptly while the write is still blocked; the data still lands
  once the write completes and is decoded back.
• TestCollector_PersistHistory_SkipsOverlappingWrites — two flushes
  triggered while a write is in flight are skipped, not queued (write
  function invoked exactly once).
• TestCollector_Run_ShutdownWaitsForFinalFlush — Run blocks until the
  in-flight final flush completes before returning, and the flushed data is
  present afterwards.
• Updated TestCollector_PersistAndLoadHistory and
  TestCollector_PersistHistory_OverwritesExistingFile to persistWG.Wait()
  after each persistHistory() call, since writes are no longer synchronous.

go build ./..., go vet ./..., go test ./... -race -cover, and
golangci-lint run all pass locally.

✅ Checklist

General

• I have added/updated tests for my changes (go test ./... -race -cover passes locally).
• go vet ./... and golangci-lint run are clean.
• I have tested my changes.
• I have read the CONTRIBUTING documentation and followed the project's code style guidelines.
• I have updated ARCHITECTURE.md if this changes a documented design decision.

REST API / configuration / packaging

Not applicable — no API, config, or packaging change.

⏭ Next Steps

The issue separately notes writeFileAtomic doesn't fsync the parent
directory after os.Rename, a minor durability gap on power loss
immediately after rename. Left out of this PR per the issue's own guidance,
as a follow-up.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud