[v3 Enterprise] PachaTree engine: tables without tags return 0 rows although the data is persisted

__Steps to reproduce:__

1. Run InfluxDB 3 Enterprise 3.11.4 on the upgraded storage engine (`--upgrade-pacha-tree`, single node, `--mode all`, `--object-store file`).
2. Write a table **without tags** and a control table **with a tag** via `/api/v3/write_lp`:
```
notag value=1.0 (7 lines)
withtag,host=a value=1.0 (7 lines)
```
3. Query immediately: `SELECT count(*) FROM notag` → 7, `SELECT count(*) FROM withtag` → 7.
4. Wait ~60 s for the snapshot. `SELECT * FROM system.pt_ingest_files` now lists the gen0 file for `notag` with `row_count = 7` and `series_key: SeriesKey::V2 { tags: [] }`.
5. Query again: `SELECT count(*) FROM notag` → **0**, `withtag` → 7. A restart does not change this.

Same effect for migrated data: after a Parquet → PachaTree upgrade (`Cluster upgrade complete`, all `system.upgrade_parquet` sources `compacted`, no errors logged), six tag-less tables with ~43k rows each return 0 rows, while all 1,100+ tables with tags match their pre-upgrade row counts exactly.

__Expected behaviour:__
Tables without tag columns are queryable on the PachaTree engine, as they are on the Parquet engine (control: same write + snapshot + restart on Parquet 3.11.4 → rows remain). Alternatively, writes to tag-less tables are rejected with a clear error (the CLI already requires `--tags` for `create table`).

__Actual behaviour:__
All queries against a tag-less table (`SELECT *`, `count(*)`, time-range filter, field aggregate, InfluxQL) return no rows as soon as the data is in `.pt` files. The data itself is persisted:
* `influxdb3 export data --database --table notag` exports the compacted windows; read with pyarrow they contain exactly the pre-upgrade row count and time range.
* `EXPLAIN SELECT count(*) FROM notag` shows normal `PachaTreeWindowExec … run_sets=[…] est_rows=…` nodes, identical in shape to a tag table.

__Environment info:__

* Official release binary `influxdb3-enterprise-3.11.4_linux_amd64.tar.gz` (revision 6ee8b0e752), not built from source.
* `Linux 7.0.14-15-pve x86_64`, Debian 13 in an unprivileged LXC container on Proxmox VE.
* 4 GB RAM, 4 vCPU (2 licensed cores, Home license), local ZFS-backed disk, `--object-store file`.

__Config:__
```
influxdb3 serve --node-id primary-node --mode all --cluster-id --object-store file --data-dir --license-type home --num-cores 2 --upgrade-pacha-tree --tls-cert --tls-key
```
All other options default. Reproduced identically with additional Parquet-era options (`--compactor-input-size-budget`, `--wal-snapshot-size`, `--exec-mem-pool-bytes`, gen1/snapshot env vars).

__Logs:__
No errors or warnings related to the affected tables; startup and migration logs are clean. Possibly related earlier fixes: 3.9.2 "Fixed compaction for tables with no tags (empty series key)", 3.11.3 "Missing rows from an OR predicate against a file index".

Reproduce the issue through /api/v3/write_lp, then inspect the PachaTreeWindowExec query path alongside system.pt_ingest_files for a tag-less SeriesKey. Compare the tag-less and tagged cases after the snapshot and restart, using EXPLAIN and exported data as evidence. Done means tag-less tables remain queryable after persistence and migration, or writes are rejected with a clear error.

Written by the indexing model from the issue text.