Add `make` command to isolate Snowcap integration-tests from contributors Snowflake account

[GClunies]

The problem

Snowcap's job is to manage real Snowflake objects, so the only way to truly verify a change is to run integration tests against a real Snowflake account. The repo already has an integration test suite for this (pytest tests/ --snowflake, ~220 tests), but running this presents some issues:

1. It is not financially feasible for Datacoves/Snowcap to provide a snowflake account to facilitate integration testing. This means contributors must bring their own account.
2. As a contributor, I never want to run Snowcap integration tests in my personal or employer's account. I only want to run a published version of Snowcap in those accounts - they are not a testing ground for OSS, even if I intend to manage them with Snowcap.

What a solution needs to do

• Contributor can easily spin up an new, isolated account from their existing snowflake organization to run snowcap integration tests against in isolation.
• There should be ZERO risk of leakage between the contributors personal/employer Snowflake account and the one used for Snowcap integration testing.

Acceptance Criteria

• A single command (e.g. make provision-test-account) creates a brand-new, empty account inside the contributor's own Snowflake organization, dedicated to Snowcap integration testing
• By default the new account mirrors the contributor's current account — same edition, cloud, and region — so feature availability matches what they develop against; explicit --edition/--cloud/--region overrides remain available
• The command bootstraps the new account with everything the suite needs (the existing test-account config + static resources) and writes a ready-to-use tests/.env pointing at it, so the next step is simply pytest tests/ --snowflake
• Zero leakage by construction: the test account's admin user is created with a freshly generated local key pair; no users, roles, credentials, network rules, shares, or data from the contributor's existing account are referenced or reused; the test suite only ever connects with the new account's credentials
• Credential separation: organization-level (ORGADMIN) credentials are used only for the create/drop steps, live in their own environment variables, and are never written to tests/.env or anything the test suite or CI reads
• A matching teardown command (e.g. make drop-test-account) drops the test account when the contributor is done (subject to Snowflake's minimum drop grace period)
• TESTING.md documents the full flow: prerequisites (a Snowflake organization with ORGADMIN enabled), provisioning, running tests, teardown, and expected cost (an idle account costs ~nothing; test runs use an XSMALL warehouse)

Resources

• tools/manage_test_account.py — already turns an existing empty account into a fully configured test account: it detects the account's edition and cloud from the live session (fetch_session()) and layers the matching configs from tools/test_account_configs/ (base + edition + cloud + compute pools). Only the account-creation step is missing — mirroring edition/cloud in the bootstrap already works by construction.
• tests/fixtures/static_resources/apply.sh / make setup-test-resources — static fixture bootstrap for a fresh account
• conftest.py — per-run test database, unique run suffix, and cleanup (isolation within the test account)
• Snowflake docs: CREATE ACCOUNT and DROP ACCOUNT (both require ORGADMIN), managing accounts in your organization
• Constraints to design around: ORGADMIN must be enabled on some account in the contributor's organization; organizations have a max-account quota; DROP ACCOUNT has a minimum grace period of days, during which dropped accounts still count against the quota