Python SDK: decide on a single auth configuration surface

[SnowboardTechie]

Summary

The Python SDK client currently supports two overlapping ways to set API key auth: Config(api_key=...) (required, falls back to CG_API_KEY) and an optional Auth passed to the client. When both are set, the explicit Auth wins and Config.api_key goes unused. This came out of review on common-grants/py-cg-grants-gov#13, where the docs example passed the same key twice.

Two consequences today:

• It's not obvious to consumers which path wins, and docs examples have duplicated the key.
• Config requires api_key unconditionally, so a client using Auth.bearer(...) still has to supply an unused API key.

For comparison, the TS SDK takes auth only through the auth option and ClientConfig carries no key.

Flagged for the next minor release of the Python SDK.

Acceptance criteria

• Direction decided and recorded on this ticket (single canonical auth surface, or keep both paths and document precedence).
• Python SDK client, README, and examples updated to match the decision.

[SnowboardTechie]

@widal001 following up from the PR #13 thread on your question about setting the key twice.

Quick recap of where things stand: the Python client takes an API key in two places. Config requires api_key (or the CG_API_KEY env var), and you can also pass an explicit Auth. When both are set the Auth wins and the Config key goes unused, which is how our docs ended up passing the same key twice. The side effect is that someone using Auth.bearer(...) still has to hand Config an API key it never uses. The TS SDK doesn't have this split, auth comes in only through the auth option and its config carries no key.

Personally I lean toward aligning with the TS shape: auth only via the Auth param, no required api_key on Config, keeping things as flexible as possible. Curious how you'd want to handle it before we lock a direction.