[nozomi_networks] Support Nozomi CMC (N2OS) endpoints

### Summary

The `nozomi_networks` integration only works against Nozomi **Vantage**. Customers who point it at a **CMC (Central Management Console)** endpoint get no data, because CMC uses a different query engine (N2OS / N2QL) whose queryable fields differ from Vantage's. Specifically, the cursor field `record_created_at` used by six data streams is **not a valid `where`/`sort` field on CMC for any source**.

Right now when users runs CMC, their `node` (and, silently, `alert`/`audit`/`health`/`node_cve`/`variable`) streams collect nothing. Their `asset` and `session` streams work because those use different cursor fields (`created_at` / `last_activity_time`).

### Why this is an enhancement, not a bugfix

The package is scoped to Vantage by design — the README states data is collected from Vantage (`packages/nozomi_networks/docs/README.md`), setup instructions reference the Vantage UI for API keys, and `observer.product` is a hardcoded `constant_keyword: Vantage` in every data stream. CMC has never been a supported target, so this is adding a new platform rather than fixing a regression. It's also not a one-line field swap:

- **The cursor field is used in three coordinated places per stream** — the `where` filter, the `sort`, and the cursor extraction (`body.result[...].record_created_at`) — so each stream needs a matched set of changes, not a single edit.
- **Six data streams are affected**: `node`, `alert`, `audit`, `health`, `node_cve`, `variable` (all query ` | where record_created_at > … | sort record_created_at asc`).
- **The correct cursor field is per-source and must be validated on CMC**, since queryable fields differ between the two engines. Candidates seen in the data are `created_at`, `last_activity_time`, and `time`, but the right one depends on the source and on wanting a field that advances on record *update* (so existing-entity changes are re-ingested), not just on creation.
- **Existing Vantage users must not break.** A blanket switch to CMC fields could regress Vantage, so this likely needs the platform (or cursor field) to be **configurable** — e.g. a package/stream variable selecting Vantage vs CMC, or an explicit cursor-field setting — with sensible defaults.
- **`observer.product` should reflect the actual platform** (currently hardcoded to `Vantage`), so CMC-sourced data isn't mislabelled.
- **Tests, fixtures, sample events, and docs** need CMC coverage: new system-test mock responses, and documentation for CMC setup (API key generation and query differences vs Vantage).

### Verified field-support matrix (from CMC + Vantage sandbox testing)

| Query source | Vantage | CMC (N2OS / N2QL) |
|--------------|---------|-------------------|
| `nodes`, `alerts`, `health_log`, `node_cves`, `variables` | `record_created_at` works | `record_created_at` **fails** (`Syntax not supported (record_created_at)`) |

### Proposed scope

- Decide the mechanism: a `platform` variable (Vantage/CMC) driving per-source cursor fields, or an explicit per-stream cursor-field variable.
- Determine and validate the CMC-supported cursor field for each of the six sources against a CMC instance.
- Update the `where` filter, `sort`, and cursor extraction consistently in each affected stream.
- Make `observer.product` reflect the selected platform.
- Add CMC system-test fixtures and update setup docs.

### Open questions

- Do we support CMC via a config toggle, other mechanism?
- Which cursor field per source on CMC gives correct incremental behaviour (captures updates, not just new records)?

### Related

- Related pipeline-error fix (separate): #20702 / #20849.