Arrow IPC and measurement endpoints create no query-history entries

Found while implementing #728.

`Register` has a single call site, `internal/api/query.go` inside `executeQuery`, which serves `/api/v1/query` and `/api/v1/query/msgpack`. Two other query endpoints never register at all:

- `POST /api/v1/query/arrow` (`executeQueryArrow`) applies the governance row cap and sets the `Arc-Rows-Capped` trailer, but creates no history entry
- `GET /api/v1/query/:measurement` (`queryMeasurement`) applies the cap and marks the envelope, but creates no history entry

So those queries are invisible to `GET /api/v1/queries/active` and `/history`, and `DELETE /api/v1/queries/:id` cannot cancel them. An Arrow IPC client can run expensive queries that never appear on the surface built to watch queries.

Adjacent to #728 but distinct: there a registered query was recorded misleadingly, here the queries are absent rather than misreported. #728 states the limitation in the 26.09.2 release notes rather than papering over it.

Fixing it means calling `Register` in both handlers and disposing on every exit path, including the panic path from #717 and the truncation paths from #721/#723.

Worth calling out in release notes when it lands: registering these endpoints also makes them cancellable, so an admin could terminate an Arrow IPC query that today cannot be stopped.

Start in internal/api/query.go with executeQueryArrow and queryMeasurement, then read Register and the existing executeQuery disposal paths. Trace normal, truncation, and panic exits, including the behavior described in #717, #721, and #723. Done means both endpoints create query-history entries, dispose them on every exit, and expose the queries to cancellation and active/history listings.

Written by the indexing model from the issue text.