SPIKE: Reuse the connection's global API key as the connector Kafka keypair

**SPIKE (research + analysis, then revise into a concrete ask).** Time-boxed investigation; the deliverable is findings + a recommendation, not shipping code.

## Motivation

After #122, `create_connector(...)` requires the caller to supply `kafka.api.key` / `kafka.api.secret` inside the `config` map — the Connect v1 create body marks both required (`config.required` in `connect/openapi.yaml`). But a connection may *already* have been handed a **global API key pair** at `connect()` time. Forcing the user to re-provide a Kafka keypair for every connector is friction we may be able to remove: if the global pair can stand in as the connector's Kafka credential, the user provisions one secret in one place.

## Research questions

- **Can a global/cloud API key actually function as a connector's `kafka.api.key`?** The connector's Kafka credential is conceptually a *cluster-scoped* (Kafka) key; a global key is a *cloud-resource* key. Determine empirically whether Connect accepts a cloud/global key in that slot, or whether it must be a cluster key.
- **Is `kafka.auth.mode: SERVICE_ACCOUNT` (with `kafka.service.account.id`) the cleaner path** to "no per-connector keypair," rather than reusing the global key? Compare the two approaches.
- **Security / blast-radius implications** of injecting a broadly-scoped global key into per-connector configs that are persisted server-side (redacted on read-back, but stored). Is that an acceptable default, or strictly opt-in?
- **Interaction with the dedicated `connect_api_key`** added in #122: those auth the *control-plane* create call; the Kafka keypair auths the *connector→cluster* data path. Confirm they're genuinely independent and document the distinction.

## Possible outcome

If reuse is viable and safe, revise this into a concrete implementation ask — likely an **opt-in `connect()` boolean** (working name `use_global_api_key_as_connector_kafka_api_key`) that, when set and a global pair is present, auto-injects `kafka.api.key` / `kafka.api.secret` into any `create_connector` config that omits them. The corresponding loosening of `build_create_payload`'s required-key check would be part of that follow-up, not this spike.

If reuse is *not* viable (or service-account mode is clearly better), the deliverable is that finding plus a recommendation for the better ergonomics path.

Child of #121.