feat: default to key-pair login for Snowflake workspaces - #93

Unclear server 400 when the default backend can't be resolved. If the token verify response has no owner.defaultBackend (e.g. a restricted token), _get_default_backend() returns None, so with an explicit login_type this sends loginType without backend (requests drops None values from form data) — exactly the combination the comment above says the API rejects. The caller gets an obscure server-side 400.

Suggestion: if effective_backend is None and login_type is not None, raise a clear client-side ValueError explaining that a backend must be passed explicitly.

Fixed in 478659d — create() now raises a clear ValueError when login_type is set but neither an explicit backend nor a resolvable project default backend is available.

Extra HTTP round-trip on every create() without an explicit backend. Every call now pays a GET /v2/storage/tokens/verify, even when the result is discarded (non-snowflake projects) or login_type is explicitly 'none'/legacy. Bulk workspace creation performs N identical verify calls, and a transient verify failure now fails a create() that previously made exactly one request.

Suggestion: cache the resolved value on the instance (e.g. self._default_backend, resolved lazily on first use) — a project's default backend is effectively immutable for the client's lifetime.

Fixed in 478659d — the resolved default backend is now cached on the instance (self._default_backend, resolved lazily on first use), so repeated create() calls pay the verify round-trip only once. Covered by a new test.

Explicit login_type='default' is silently rewritten to key-pair. 'default' is a valid API value (password login), so a caller explicitly asking for it gets a key-pair workspace instead, and their subsequent response['connection']['password'] read raises KeyError. It is documented in the docstring, but the more conventional behavior would be to only apply the default when login_type is None and pass an explicit 'default' through to the server. If the current behavior is intentional, consider keeping it — just flagging the trade-off.

Intentional — the goal of this change is that no code path silently produces a deprecated password workspace, and an explicit 'default' resolves server-side to the same snowflake-legacy-service password login as an omitted value. This mirrors how connection's own test tooling (StorageApiTestCase::prepareWorkspaceCreateOptions) rewrites null/default. Callers who genuinely want a password workspace must opt in with login_type='snowflake-legacy-service'. Documented in the docstring.

Client-generated private key is spliced into the server response. After this, connection.privateKey is indistinguishable from server-returned data; callers that log or persist the whole create() response (a common pattern) will write an unencrypted PKCS#8 private key into logs/storage. Consider returning it separately (e.g. a tuple or a dedicated documented key outside connection), or at minimum call this risk out in the changelog.

Keeping as-is, deliberately: credentials living under connection is the established contract of this client (password workspaces return connection.password the same way), and connection's PHP test tooling splices the locally generated privateKey into connection identically. Returning it out-of-band would break the drop-in usage for callers switching from password to privateKey. The logging/persistence risk applies equally to the server-returned password today; the docstring calls out that the private key is only available at creation. Will flag it in the release notes.

Missing coverage: backend omitted on a non-snowflake project. Every test either forces backend explicitly or mocks verify to return snowflake. A regression in the branch where verify returns e.g. bigquery (must send neither loginType nor publicKey, backend stays None) would pass the suite unnoticed. Suggest adding a test with verify_token_response patched to a non-snowflake defaultBackend.

Fixed in 478659d — added test_create_non_snowflake_default_backend_unchanged: verify resolves bigquery and the create request must contain neither backend, loginType nor publicKey.

Nit: keypair_create_response is a 25-line copy of create_response differing only in the connection block. Deriving it keeps the two from drifting:

keypair_create_response = {
    **create_response,
    'connection': {
        **{k: v for k, v in create_response['connection'].items() if k != 'password'},
        'loginType': 'snowflake-service-keypair',
    },
}

Fixed in 478659d — keypair_create_response is now derived from create_response (password dropped, loginType added).

Fixed in ecb6a26 — the body is now filtered with the same if v is not None comprehension as triggers.py. (For the record, requests drops None values from form data, so they were never serialized as empty parameters — but the explicit filter states the intent and makes the stricter test assertions meaningful.)

Fixed in ecb6a26 — _default_backend now starts at a module-level sentinel, so a resolved-but-missing default backend is memoized too. The ValueError test now calls create() twice and asserts verify ran only once.