feat(hunt-io): add support for hunt v3 c2 feed api

[m4r35]

Use case

Hunt.io serves its C2 feed from two APIs that use mutually exclusive authentication schemes:

API	Endpoint	Auth header	Key format
V2	https://api.hunt.io/v1/feeds/c2	token: <key>	any
V3	https://a.hunt.io/feeds/c2	Authorization: Bearer <key>	ak_-prefixed

Each returns HTTP 401 when sent the other's header.

HTTPSessionManager.create_session in the hunt-io connector hardcodes the token header:

session.headers.update({"token": api_key})

so the connector can only talk to V2. Users whose Hunt.io access is on V3 cannot use the connector at all.

Current workaround

None within the connector. Pointing HUNT_IO_API_BASE_URL at the V3 endpoint does not work, because the
auth header is unchanged and every request returns 401. The only option is to remain on V2.

This is also hard to diagnose: V3 returns an identical, opaque 401 for a missing key, a malformed key,
and a wrong-scheme key, so the failure gives no indication that the header is the problem.

Proposed solution

Add an optional hunt_io.api_version setting (HUNT_IO_API_VERSION) accepting v2 (default) or v3,
which selects the matching auth header.

• Backward compatible. The default reproduces today's behaviour exactly, so no existing deployment
  is affected and nothing becomes mandatory.
• No parsing changes. Both APIs return content-type: application/gzip containing gzipped NDJSON,
  with the same record fields (ip, port, hostname, timestamp, scan_uri, confidence,
  extra, malware_name, malware_subsystem). Conversion and STIX generation are untouched.
• Fail fast on a malformed V3 key. Reject a non-ak_ key at startup when v3 is selected, turning
  the opaque runtime 401 into a clear configuration error. Deliberately scoped to V3 only, since V2
  documents no prefix rule.

api_version and api_base_url must be set together; documentation should call that out, since
changing only one produces the 401 described above.

Additional information

Both paths verified end-to-end against the live APIs on OpenCTI 7.260910.0: authentication, feed
fetch, STIX conversion, and ingestion of observables, indicators, malware, infrastructure and
relationships — with no errors from the connector, workers, or platform.

If the feature request is approved, would you be willing to submit a PR?

Yes, the implementation is ready, including unit tests and regenerated __metadata__.