M9: GPU backend

Tracking issue for **M9**. Specification: [`05-kernels.md`](../blob/main/docs/specs/05-kernels.md), [`10-benchmarks.md`](../blob/main/docs/specs/10-benchmarks.md).

### Scope

- [ ] Device affinity on the operator interface
- [ ] `DeviceContext` acquisition guarded by `has_accelerator()`
- [ ] Device-resident buffers
- [ ] Transfer nodes visible in `explain()`
- [ ] A cost model that refuses to move data for work that will not pay for the transfer
- [ ] Port the aggregation, join, filter and sort kernels — mostly a launch and indexing change rather than a rewrite

### Exit criteria

- [ ] db-benchmark group-by queries run on a GPU and the results are published **next to cuDF's**
- [ ] The whole library builds, tests and passes on a machine with no accelerator, with every GPU test skipped rather than failed, and the skipping reported in the summary rather than silently passing
- [ ] The cost model's threshold is derived from measurement and is in a table somebody can read

### The honest framing

cuDF got here first and is mature. What firepanda has that it does not is that a user-defined function written once runs on both devices in the same language. That is the claim, and it is the only claim.

If the benchmarks say we lose, they get published saying we lose. Do not report a GPU number against a CPU baseline without also reporting cuDF; the interesting comparison for a GPU dataframe is another GPU dataframe.

### Depends on

M5 and M8.

Read docs/specs/05-kernels.md and docs/specs/10-benchmarks.md first, then verify the M5 and M8 dependencies are complete. The work spans device affinity, buffers, transfer visibility, cost modeling, and several kernels. Done means GPU benchmarks are compared with cuDF, no-accelerator builds skip and report GPU tests, and the measured threshold is documented in a readable table.

Written by the indexing model from the issue text.