Fix wrong sort order at UTC month boundaries and pre-release versions

[elias-ba]

Description

Several places in the codebase used Enum.sort_by(.., :asc | :desc) (or the equivalent Enum.sort/2 form, or <=/>= as a comparator) on a key whose value was a DateTime or a Version struct. That form does Erlang structural term comparison, which on these structs walks fields alphabetically and disagrees with chronological / semver order. Same root cause across four surfaces.

• Workflow list, "Latest Work Order" column (project dashboard). Sorted incorrectly when the most recent work orders for two workflows fell on either side of a UTC month boundary.
• Projects list, "Last Updated" column, support-user view. Same shape, same trigger. Non-support users were unaffected; they go through a SQL order_by.
• Admin tables that sort on date columns ("Created at" and "Scheduled deletion" on the admin projects table, "Scheduled deletion" on the admin users table). All go through a shared TableHelpers.sort_items/4 helper, which used <=/>= (structural compare) and produced the same inversion at month boundaries.
• Adaptor version dropdown. Listed pre-release versions above their corresponding stable release because the sort relied on structural compare of parsed version structs.

Each fix maps the sort key through a domain-aware comparator: DateTime becomes integer microseconds (or ISO 8601 strings inside the shared table helper), version strings go through Version.compare/2. The dashboard, projects-overview, and admin-table fixes have real user impact at month boundaries. The adaptor version fix is a real-but-currently-zero-impact correction (OpenFn adaptors essentially always ship plain X.Y.Z semver, so today no user is hitting it; included here because it is the same root cause).

Validation steps

1. Run the affected test files together:

   mix test \
     test/lightning/dashboard_stats_test.exs \
     test/lightning/projects_test.exs \
     test/lightning_web/live/helpers/table_helpers_test.exs \
     test/lightning_web/live/job_live/adaptor_picker_test.exs
   

   All tests pass on this branch, including four new regression tests that pin chronological / semver ordering across boundaries.

2. Quick spot-check in iex -S mix:

   # DateTime sort, dashboard / projects family
   stats = [
     %Lightning.DashboardStats.WorkflowStats{workflow: %{name: "older"}, last_workorder: %{updated_at: ~U[2026-04-30 23:10:00Z]}},
     %Lightning.DashboardStats.WorkflowStats{workflow: %{name: "newer"}, last_workorder: %{updated_at: ~U[2026-05-01 01:10:00Z]}}
   ]
   Lightning.DashboardStats.sort_workflow_stats(stats, :last_workorder_updated_at, :desc) |> Enum.map(& &1.workflow.name)
   # On this branch: ["newer", "older"]. On main: ["older", "newer"].
   
   # Admin tables sort helper
   items = [
     %{name: "April", inserted_at: ~U[2026-04-30 23:10:00Z]},
     %{name: "May", inserted_at: ~U[2026-05-01 01:10:00Z]}
   ]
   LightningWeb.Live.Helpers.TableHelpers.sort_items(items, "inserted_at", "desc", %{"inserted_at" => :inserted_at}) |> Enum.map(& &1.name)
   # On this branch: ["May", "April"]. On main: ["April", "May"].
   
   # Version sort, adaptor family
   LightningWeb.JobLive.AdaptorPicker.sort_versions_desc(["1.0.0", "1.0.0-beta", "1.0.0-alpha"])
   # On this branch: ["1.0.0", "1.0.0-beta", "1.0.0-alpha"]. On main: ["1.0.0-beta", "1.0.0-alpha", "1.0.0"].

Additional notes for the reviewer

AI Usage

• I have used Claude Code
• I have used another model
• I have not used AI

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review with Claude Code)
• I have implemented and tested all related authorization policies. (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[github-actions]

The change is purely an in-memory sort comparator fix in dashboard_stats.ex — no new queries, web entrypoints, or config-resource writes. All three checks are N/A.

Security Review ✅

• S0 (project scoping): N/A, the change only swaps a sort-key fallback (~U[1970-01-01] → 0 unix-µs) inside sort_workflow_stats/3; no queries or data access altered.
• S1 (authorization): N/A, no new web-layer actions, controllers, or LiveView events are introduced.
• S2 (audit trail): N/A, no config-resource writes or Repo.insert/update/delete calls in the diff.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.89%. Comparing base (bef2bc2) to head (73e8d26).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4687   +/-   ##
=======================================
  Coverage   89.88%   89.89%           
=======================================
  Files         444      444           
  Lines       21941    21951   +10     
=======================================
+ Hits        19722    19733   +11     
+ Misses       2219     2218    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[taylordowns2000]

Approved, but please update the changelog (link to the issue or the PR itself) and consider these before merging:

1. What was using the DateTime that you're now converting to Unix? Do all those downstream sites (maybe UI displays of the dates?) now need updating too?
2. Does the nil -> 0 branch map missing timestamps to the Unix epoch? Mixing "absent" with "1970-01-01" would not be great.

[midigofrank]

Nicely done @elias-ba , I'm just not sure why we need the 0 and 1,
why can't we do DateTime.to_unix("1970-01-01") when it's nil? The tuple makes it feel complicated

[elias-ba]

@midigofrank thanks for the review man! I totally hear you on the tuple feeling complicated, and I went back and forth on it myself. Let me explain where the 0 / 1 shape came from.

There's a business requirement we need to honor: a nil row and a hypothetical real ~U[1970-01-01] row must not tie at the comparator level. The reason your suggestion of mapping nil to DateTime.to_unix(~U[1970-01-01 00:00:00Z], :microsecond) doesn't quite get us there is that the result of that conversion is exactly 0, which is the same value a real ~U[1970-01-01] row would produce. So the two cases would collapse to the same sort key.

The tuple is the smallest change I could find that keeps both worlds:

• Second slot is unix microseconds, so the chronological compare works exactly the same as your suggestion.
• First slot tags nil vs present, so the two cases stay structurally distinct regardless of what value lands in the second slot.

We also shipped this same shape in the billing app for the same root-cause class, so I'd like to keep it consistent here too.

[midigofrank]

Aaah, okay. Makes sense