Require julia 1.10

[davidanthoff]

ParquetFiles now reads via Parquet2.jl (queryverse/ParquetFiles.jl#43), which requires julia 1.10.

Without raising the floor here too, Queryverse on an older julia cannot resolve the new ParquetFiles and would silently fall back to ParquetFiles 0.2.0 — the version that depends on the Parquet.jl → Thrift → BinaryProvider chain that is no longer installable, which is exactly what that change fixes.

The ParquetFiles = "0.2, 0.3, 1" compat entry already accepts the new version, so the julia floor is the only edit. No source changes.

Verified locally: with ParquetFiles#43 dev'd, using Queryverse loads and DataFrame(load("nation.impala.parquet")) returns the expected 25×4 table.

CI cannot go green until ParquetFiles is released

This PR's CI still fails, and that is expected: Queryverse resolves ParquetFiles v0.2.0 from the registry, not the branch in queryverse/ParquetFiles.jl#43. That old release pulls Parquet 0.3.2 → Thrift → BinaryProvider, and the resolver rejects it outright:

└─Thrift [8d9c9c80] log:
  ├─possible versions are: 0.5.1 - 0.8.6 or uninstalled
  └─restricted by compatibility requirements with BinaryProvider [b99e7846] to versions: 0.7.0 - 0.8.6 or uninstalled
    └─BinaryProvider [b99e7846] log:
      ├─possible versions are: 0.4.0 - 0.5.10 or uninstalled
      └─restricted by julia compatibility requirements to versions: uninstalled

Pkg.resolve fails before any test runs. This is exactly the breakage ParquetFiles#43 fixes, so these legs should go green once ParquetFiles 1.0.0 is registered — this PR should be merged/re-run in that order.

For reference, Julia CI on main is already failing for the same reason (63 of 80 legs). The julia floor bump here shrinks the matrix from 80 legs to 29 but cannot fix the resolution failure on its own.

Note also that the 32-bit legs fail independently, on a PyCall/conda i686 build error unrelated to any of the above.