fix: apply each combination part to the whole of what precedes it

[matt-beanland]

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

Fixes #243.

Ash.Query.combination_of/2 takes an ordered list of parts, and each part applies to the result
of everything before it. There is no precedence between the combination types — the order in the
list is the order of application.

combination_of/4 appends each operation onto the accumulated query, which renders as one flat
chain of set operations. SQL then applies its own precedence to that chain, and INTERSECT binds
tighter than UNION/EXCEPT, so a combination spanning more than one precedence level gets
regrouped. Given base, union, intersect, the intersect is applied to the union's right
operand rather than to the running result:

SELECT ... FROM (SELECT ... WHERE region = $1) AS ss0
UNION (SELECT ... WHERE name = $2)
INTERSECT (SELECT ... WHERE price = $3)

The consequence is a query whose meaning depends on its data layer. Ash.DataLayer.Ets applies
the parts in the order given, so on identical data the two answer differently:

data layer	result
AshPostgres.DataLayer	["alpha", "beta", "gamma"]
Ash.DataLayer.Ets	["alpha", "gamma"]

The change

Nest what has accumulated before applying the next part, so each operation takes everything
preceding it as its left operand:

query =
  case query do
    %Ecto.SubQuery{} -> query
    query -> subquery(query)
  end

A part already wrapped as a subquery is left alone, so this adds one level of nesting per part
rather than one per part plus a trailing one.

Verification

ash_sql's own suite has no database and no combination coverage, so this was verified against
ash_postgres built with ASH_SQL_VERSION=local, on ash_postgres fc165f3e:

• test/combination_test.exs — 18 passed, unchanged. All 18 stop at two parts, which is why this
  has not surfaced: two-part combinations always agree, and union/except share a precedence
  and are left-associative in SQL, so those agree too. It needs three or more parts spanning more
  than one precedence level.
• The three-part case added in ash_postgres#811 returns the order as given only with this change —
  ["alpha", "gamma"] with it, ["alpha", "beta", "gamma"] without.
• Full suite: identical results with the released ash_sql 0.6.6, with ash_sql main, and with
  this branch — 874/885 in all three, and the failing set is byte-identical across them. Those
  11 failures are all in AshPostgres.AggregateReadActionTest, reproduce against released
  ash_sql, and are unrelated to this change.

Tests

The regression test is in ash_postgres#811, following the pattern used for #239 and
ash_postgres#797 — ash_sql has no database of its own, and all the combination tests live over
there. It fails against ash_sql 0.6.6 and passes with this branch, so it doubles as the
reproduction.

[zachdaniel]

🚀 Thank you for your contribution! 🚀