PR Review: Refactor issue creation from IO to Eff

Overall this is a clean, well-scoped refactor. The direction is correct and the changes are minimal. A few observations:

Behaviour change: timezone semantics

utcToLocalZonedTime (removed) uses the system's local timezone at runtime. utcToZonedTime utc (added) always produces a ZonedTime in UTC. This is a silent semantic change, not just a mechanical lift.

• For createRuntimeExceptionIssue: atError.when is a UTCTime, so the old code would display it in the server's local TZ; new code always stores it as UTC. Likely an improvement for consistency, but worth confirming the stored ZonedTime is rendered/interpreted correctly downstream (e.g. in the UI or DB serialisation).
• For createQueryAlertIssue: same consideration for createdAt/updatedAt.

If UTC is the intended canonical timezone everywhere, this is the right fix — just flag it explicitly in the PR description so reviewers know it's intentional.

createAPIChangeIssue: now was unused before and is gone now

In the old signature getCurrentTime was called but the resulting now doesn't appear to have been used in createdAt/updatedAt (those fields seem to be filled from the anomaly data or left as defaults). Dropping it is correct — just worth a quick sanity check that the Issue fields that used to be set from now are still populated correctly.

Inconsistency: two UUID generation styles still coexist in BackgroundJobs.hs

Lines 977 and 1345 still use liftIO UUIDV4.nextRandom for report/dashboard IDs while the rest of the file now uses UUID.genUUID via UUIDEff. This is pre-existing, not introduced here, but since this PR is specifically about moving UUID generation into the effect system, it may be worth a follow-up (or a note in the PR) to handle those remaining sites for consistency.

Minor: constraint ordering convention

-- PR adds:
createQueryAlertIssue :: (Time :> es, UUIDEff :> es) => ...

-- Other signatures in this file use:
createAPIChangeIssue :: UUIDEff :> es => ...

No issue with either, but if the codebase has a convention for ordering constraints (e.g. alphabetical, or "more specific first"), it's worth aligning.

Summary

The timezone behaviour change is the only thing worth a explicit confirmation before merge.