Refetch a maintenance only when its status will change

[Aloento]

Summary

Cut the per-tick query count of the maintenance scan. The checker now refetches an event only when the batch-loaded state disagrees with the status it would compute, instead of one GetIncident per event. The event set is still scanned in full, so out-of-band database edits stay reconciled.

Changes

• Compute the target status from the batch-loaded statuses; refetch and run the version-checked WithTx only when the status changes.
• Drop the WithComponents preload from the checker's event query; the checker never reads components.
• Add TestNeedsRefetch and TestChecker_SteadyState_SkipsRefetch.

Verification

• go build ./..., go vet ./..., go test -count=1 ./internal/... - pass
• go test -c ./tests/ compiles; the integration suite needs Docker and runs in CI

No new configuration and no new migrations.

[Aloento]

@ecosquad-autoreview review 

[ecosquad-autoreview]

Summary

This PR cuts per-tick GetIncident round-trips from the maintenance checker: processMaintenance now only refetches (and only runs the version-checked WithTx write) when the batch-loaded state disagrees with the status the checker would compute. It also drops the now-unused WithComponents preload from the shared getEventsByType query. CI is green (build, vet, unit tests, Docker acceptance tests, CodeQL, lint).

I verified the optimization is sound and the preload removal is safe. No blocking issues; approved.

Correctness (verified, no issues)

• internal/checker/maintenance.go (~line 87, needsRefetch) — the skip decision compares mn.Status against calculateCurrentMntStatus(calculateMntStatusHistory(mn), mn), which is exactly the value evaluateAndFixMntStatus returns. So !needsRefetch(mn) is a faithful early exit: the same code that used to compute actualStatus and find mn.Status == actualStatus (and no-op) now short-circuits before the refetch. Behavior for the write path (refetch → recompute → WithTx modify+publish → Notify) is unchanged, so the version-conflict window and notification semantics are preserved. The second check (fresh.Status == actualStatus) after the refetch is still needed and correctly retained, covering the race where the batch state flagged a change but the fresh read is already at the target.
• Out-of-band reconciliation — every event is still scanned in full each tick; only the refetch/write is conditional. Manual DB edits that change status or backfill state still produce needsRefetch == true and get reconciled, as the PR claims.
• internal/db/event_types.go (getEventsByType) — this helper is shared by GetMaintenances and GetInfoEvents. I checked both consumers: internal/checker/maintenance.go and internal/checker/info.go never read Components (only Status, dates, Text, ContactEmail, Statuses). No other callers exist, and build + acceptance tests confirm nothing depends on the edge being preloaded. Safe to remove.

Suggestions (non-blocking)

• internal/checker/info.go (~line 63, pre-existing, not introduced by this PR) — CheckInfoEvents calls fixInfoMissedStatuses(...) before the if info.Status != actualStatus guard, so on every tick for a steady-state active info event it appends a redundant status entry in memory (no-op'd by the guard, then discarded since ModifyIncident is skipped). It's harmless today only because the discarded object is thrown away, but it's dead work per event per tick and will be a bug the moment anyone adds a side effect inside fixInfoMissedStatuses. The maintenance side of this PR now avoids exactly this pattern via needsRefetch. Consider mirroring that guard (if info.Status != actualStatus { fix + ModifyIncident }) in a follow-up, and be aware that if the info path ever needs to persist backfilled intermediate statuses, that logic currently lives after the no-change guard.
• internal/checker/maintenance_test.go (TestNeedsRefetch) — nice table tests. One untested case worth adding: a MaintenanceInProgress event with a nil EndDate (open-ended, steady-state, expects false) — it exercises the nil-pointer branch of calculateCurrentMntStatus that the existing "completed" case doesn't reach.
• tests/checker_notifications_test.go — the new TestChecker_SteadyState_SkipsRefetch is a good acceptance-level guard on version bumps and outbox rows. A matching test for the transition path under this optimization (planned with a past start date → in_progress, asserting exactly one version bump and one outbox row across a scan) would pin the refetch path symmetrically.

Verdict

Approve. The change is correct, well-tested, and the perf win is real for large event sets. The suggestions are optional follow-ups.