Revisit SSL context fallback behavior when system CA store is unavailable

Start by reading the SSLContextFactory path around set_authority(None)? and the set_client_verify(false) fallback. Determine the intended behavior when the system CA store is unavailable, then define and implement a decided warning, failure, or configuration policy with coverage for that fallback path.

SSLContextFactory attempts to create a verified SSL context via set_authority(None)?, which asks OpenSSL to use the default system CA store. When the CA store isn't discoverable (e.g. WSL2 without ca-certificates), this fails. Currently we fall back to set_client_verify(false), matching what ponylang/http's HTTPClient did silently.

This means every API call from the library — not just examples — silently downgrades to unverified HTTPS when no CA store is found. That's fine for local development but worth thinking through for a library that sends auth tokens over the wire.

Questions to consider:

• Should the library warn or fail loudly when falling back to unverified SSL?
• Should this be configurable via Credentials or a separate option?
• Is the silent fallback actually the right default for a GitHub API client?