[codex] Add SQLite aggregate support

[wtsnz]

This is my first proper dive into extending the Ash ecosystem, so I’m still getting my bearings with some of the internals and conventions.

I needed aggregates for a local app I’m building on SQLite, and spent the last couple of days exploring the existing SQL adapters and getting this branch into shape with Codex helping lots along the way. My goal was to get most of the common usage of aggregates working with sqlite so that I could continue building my app.

I took a look at what AshPostgres supports - the tests helped a lot to get an idea of what to support - and tried to get most of it working in SQLite.

Summary

This covers the aggregate kinds I most wanted to use day-to-day:

• count
• sum
• avg
• min
• max
• exists
• first
• list
• SQLite-compatible custom aggregates

This also adds AshSqlite.CustomAggregate that follows the same general idea as AshPostgres.CustomAggregate - you've just got to make sure that you emit SQLite-compatible SQL.

Approach

I originally hoped this could mostly reuse the shared ash_sql aggregate machinery, but the existing aggregate planner is built around SQL shapes SQLite does not support cleanly. Lateral joins and PostgreSQL-style list aggregation are the big ones. For SQLite, the safer route (according to the LLMs!) is grouped/windowed subqueries, JSON aggregation for lists, and explicit errors when a filter shape could multiply the rows being aggregated.

So this different approach requires us to add our own SQLite-specific aggregate planner in AshSqlite.Aggregate.

The implementation builds aggregate queries as grouped subqueries or windowed subqueries, then joins those results back to the parent query. Scalar aggregates can often share grouped subqueries. first and list need window/query handling so ordering stays deterministic, and list uses SQLite JSON aggregation before being decoded back into the loaded aggregate value.

A lot of the work here is defensive so that AshSqlite does not generate SQL that returns subtly wrong results. Aggregate filters that join across to-many relationships can accidentally multiply rows and over-count or over-sum. For those cases, I've tried to either use a safe shape or return an explicit unsupported error. I've made sure to add enough tests to be confident in the implementation.

Future potential

This pr is intentionally SQLite-scoped rather than full AshPostgres parity, and already does pretty much everything I need for my project so far.

The main things I’ve left out are cases where SQLite would need a very different query shape, or where the generated SQL could quietly return the wrong answer. That includes things like parent-dependent aggregate filters, manual relationships, some mixed multi-hop/many-to-many paths, and fanout-prone filters over to-many relationships.

Those cases should fail with explicit unsupported errors rather than producing over-counted or over-summed results. The docs include the fuller list of current limitations.

Validation

• MIX_ENV=test mix test.reset
• MIX_ENV=test mix test

Latest local result: 187 tests, 0 failures.

Contributor checklist

Leave anything that you believe does not apply unchecked.

• I accept the AI Policy, or AI was not used in the creation of this PR.
• Bug fixes include regression tests
• Chores
• Documentation changes
• Features include unit/acceptance tests
• Refactoring
• Update dependencies