Improve v1/v2 API clarity, compatibility guides, and client library guidance

## Summary

Users migrating from InfluxDB v1 to InfluxDB 3 face fragmented documentation across API specs, client library pages, and compatibility guides. Key information about which protocols client libraries use, which endpoints map to which use cases, and how to plan a migration is either missing, vague, or scattered across unrelated nav sections.

---

## 1. Enterprise v1 content page bugs and gaps

The Enterprise v1 API reference content page (`content/enterprise_influxdb/v1/tools/api.md`) has gaps compared to the OSS v1 page (`content/influxdb/v1/tools/api.md`).

### Bugs

- **`/ping` example shows `OSS` build type** (line ~434): Response header shows `X-Influxdb-Build: OSS` — should be `ENT`
- **Typo** (line ~1116): "Unaccetable" should be "Unacceptable"

### Missing content

- **"InfluxDB 3 compatibility" section**: OSS v1 has a section (lines 40-55) explaining that InfluxDB 3 supports v1 `/write` and `/query`. Enterprise v1 omits this entirely.
- **`alt_links` frontmatter**: OSS v1 has `alt_links: v2: /influxdb/v2/reference/api/`; Enterprise v1 has none
- **v1 client libraries recommendation note**: OSS v1 recommends v1 client libraries for InfluxDB 3 compatibility; Enterprise v1 omits this
- **`/debug/pprof/all` version note**: OSS v1 documents a behavior change for 1.8.3 and earlier; Enterprise v1 omits this

### Spec vs content gap

- **`/shard-status` endpoint**: Documented in Enterprise content page but was missing from the OpenAPI spec. Fixed in #6622.

---

## 2. v1 API spec gaps

Both `api-docs/influxdb/v1/influxdb-oss-v1-openapi.yaml` and `api-docs/enterprise_influxdb/v1/influxdb-enterprise-v1-openapi.yaml` have coverage gaps:

- **Missing response format**: `/query` supports `application/x-msgpack` but only documents JSON and CSV
- **Missing parameter**: `/query` supports `chunk_size` (separate from `chunked`) — undocumented
- **Missing header**: `/write` accepts `Content-Encoding: gzip` — not documented as a header parameter
- **Missing error codes**: `/query` POST omits `403 Forbidden` (insufficient privileges)
- **Vague schema**: `/debug/vars` returns `type: object` with no property definitions
- **`db` required nuance**: `db` on `/query` is required for most queries but not `SHOW DATABASES` etc. — spec doesn't explain this
- **Version staleness**: OSS v1 spec hardcodes `version: 1.8.10`
- **No `x-related` links**: Both v1 `tags.yml` files have `x-related` only on Authentication — all other tags have none (compare to v3 tags.yml files which have links on every tag)

---

## 3. API compatibility guides — missing for Core and Enterprise

Clustered, Cloud Dedicated, and Cloud Serverless each have consolidated `Guides > API compatibility` sections with v1 and v2 sub-pages covering authentication, write/query parameters, supported InfluxQL, and client library examples.

**Core and Enterprise have no equivalent.** Compatibility content is fragmented across unrelated nav sections:

- Write-side: `Write data > HTTP API > Use v1 and v2 compatibility APIs`
- Query-side: `Query data > Execute queries > Use the v1 query API`

A user looking for "how do I use my v1 tools with InfluxDB 3 Core" has to discover both pages independently.

**Proposed**: Create `Guides > API compatibility > v1` and `v2` pages for Core and Enterprise, following the Clustered pattern (`content/influxdb3/clustered/guides/api-compatibility/`). Either consolidate existing content or add a landing page linking to the write/query pages.

---

## 4. Client library pages lack transport/protocol clarity

| Library category | Writes via | Queries via | Documented? |
|---|---|---|---|
| v3 client libraries | HTTP (`/api/v3/write`) | gRPC (Flight SQL) | Vaguely — says "HTTP APIs" and "Flight protocol" |
| Arrow Flight clients | N/A (query-only) | gRPC (Flight SQL / Flight RPC) | Yes — best documented |
| v2 client libraries | HTTP (`/api/v2/write`) | HTTP (`/api/v2/query` — **broken on v3**) | Warns queries don't work, doesn't explain why |
| v1 client libraries | HTTP (`/write`) | HTTP (`/query`) | No transport mentioned at all |

### What's missing

- **Protocol explainer**: No page explains the relationship between HTTP APIs (v1/v2/v3 endpoints), gRPC/Flight SQL (query protocol), and Arrow Flight RPC
- **Migration path**: No page guides users on which library to use when migrating from v1 — the practical answer is "use v3 client libraries" but this isn't stated
- **v2 library dead end**: The v2 page warns queries don't work in v3 but doesn't suggest the alternative (switch to v3 libraries)

---

## 5. v1 product nav — two competing API doc locations

The legacy hand-written API page lives at `Tools > InfluxDB API reference` (`content/influxdb/v1/tools/api.md`). The new generated API reference lives at a separate path. These aren't connected in navigation — users may find one but not the other.

Need to decide: deprecate the legacy page in favor of the generated reference, or keep both with clear cross-links and distinct purposes (tutorial-style vs reference).

---

## Proposed deliverables

- [ ] Fix Enterprise v1 content page bugs and gaps (section 1)
- [ ] Fix v1 API spec gaps — msgpack, chunk_size, Content-Encoding, error codes, x-related links (section 2)
- [ ] Create API compatibility guide section for Core and Enterprise (section 3)
- [ ] Add protocol/transport documentation to client library pages (section 4)
- [ ] Add migration guidance: which library to use when moving from v1 to InfluxDB 3 (section 4)
- [ ] Resolve dual API doc location for v1 products (section 5)
- [ ] Update OSS v1 spec version from `1.8.10`

## Related

- #6622 (API docs uplift — spec pipeline and tag cleanup)
- influxdata/docs-tooling#45 (Core/Enterprise dual-tagged operations)

Start by comparing content/enterprise_influxdb/v1/tools/api.md with content/influxdb/v1/tools/api.md, then review both v1 OpenAPI files and the clustered pattern under content/influxdb3/clustered/guides/api-compatibility/. Map the existing compatibility and client-library pages before deciding the navigation approach. Done means the documented gaps, migration guidance, compatibility structure, and v1 API locations are resolved with corresponding links and examples.

Written by the indexing model from the issue text.