Parquet upgrade status docs: missing _internal db, mode column, and what --upgrade-poll-interval affects

[jstirnaman]

Source: influxdata/DAR#748.

What changed

content/shared/influxdb3-admin/query-system-data/_index.md, "Parquet upgrade status" section
(~line 297–311). Current text:

-- Per-node upgrade status
SELECT * FROM system.upgrade_parquet_node;

-- Per-file migration progress
SELECT * FROM system.upgrade_parquet;

Monitor system.upgrade_parquet_node to confirm each node reaches completed status. The
status updates on a polling interval (default 5 seconds, configurable with
--upgrade-poll-interval).

Why

Live-verified against a Docker Enterprise 3.11.2 upgrade fixture (influxdata/DAR#748). Three
gaps, in order of how much they cost someone reading this section during a real migration:

1. Missing --database _internal. Both tables live only in _internal, not the database
   being migrated. Neither query specifies it — unlike the trigger-logs example earlier on the
   same page, which does. A query against the wrong database returns "table not found",
   indistinguishable from the table not existing. Querying the wrong database during a real
   migration returned that error at every attempt, mid-migration included; _internal on the
   same cluster returned correct data immediately.

2. "Each node reaches completed" undercounts what to watch. system.upgrade_parquet_node
   returns one row per node per mode — ingest and compactor transition separately, and
   compactor lags ingest by design. Live example, single node, still mid-migration:

   [{"node_id":"node0","mode":"ingest","status":"completed"},
    {"node_id":"node0","mode":"compactor","status":"upgrading"}]

   Reading "each node reaches completed" without knowing about the mode column risks stopping
   at the first completed row and missing that the compactor is still mid-migration.

3. No mention that --upgrade-poll-interval changes migration duration, not just polling
   cadence. The current text frames it as purely a status-refresh setting. In testing, raising
   it measurably widened how long compactor stayed upgrading (~3s at the 5s default, ~13s at
   15s) — worth a line clarifying it affects the pace of the underlying migration work, not
   just how often the status column updates.

Suggested fix

• Add --database _internal ("db": "_internal" for the HTTP example) to both queries.
• Note the mode column on system.upgrade_parquet_node (ingest, compactor) and that a
  node isn't fully upgraded until every mode's row reads completed.
• Clarify what --upgrade-poll-interval actually governs, if that's confirmed with
  Engineering — DAR#748 flags this as worth double-checking before it's stated as fact in docs.

Where this could land

Either folded into #7718, if still open, or as its own small PR — query-system-data isn't in
that PR's file list.