feat(git_repository): add GitRepository resource + grant support

[usbrandon]

Summary

Adds Snowflake GIT REPOSITORY support and fills two related gaps in integration handling that surface together when managing Git repos.

Three commits, three problems

1) feat(git_repository) — first-class GitRepository resource

GIT REPOSITORY was listed in ResourceType but had no resource class, no priv enum, and no data_provider hooks (privs.py:392 mapped it to None). Users couldn't declare grants like priv: READ on git repository <fqn>, forcing raw-SQL bridges.

• snowcap/resources/git_repository.py — GitRepository class (SchemaScope) with required origin + api_integration and optional git_credentials (secret) + comment + owner, mirroring CREATE GIT REPOSITORY syntax.
• snowcap/privs.py — GitRepositoryPriv enum (READ, WRITE, OWNERSHIP); wires into both PRIVS_FOR_RESOURCE_TYPE and CREATE_PRIV_FOR_RESOURCE_TYPE.
• snowcap/data_provider.py — fetch_git_repository (uses SHOW GIT REPOSITORIES) and list_git_repositories (via list_schema_scoped_resource). Auto-discovered by the existing fetch/list dispatch.
• snowcap/resources/__init__.py — exports GitRepository.
• Docs + unit tests + integration fetch test + JSON/SQL fixtures.

2) fix(grant) — on: list parser for plain-object grants + multi-word types

The on: string parser only recognized single-word resource types (schema, database, warehouse), so on: git repository <fqn> — and incidentally on: api integration <fqn>, on: network rule <fqn>, on: image repository <fqn>, on: external access integration <fqn> — failed with Grant type not recognized. Fixed with a longest-match look-ahead across consecutive words.

Separately, the list form of on: was treated as multiple grants ONLY if every list item contained FUTURE or ALL. Plain-object lists like on: [warehouse FOO, warehouse BAR] or on: [git repository D.S.A, git repository D.S.B] were misinterpreted as a single multi-element grant spec, again hitting "Grant type not recognized." Fixed by inspecting the first element: form (1) keeps its 4-element semantics if on[0] is FUTURE/ALL; otherwise each item is its own complete on spec and gets queued via rest_of_ons.

3) feat: generic INTEGRATION grants + APIIntegration non-AWS subtypes

Surfaced while migrating GitHub-related grants:

• ResourceType.INTEGRATION (umbrella) had no RESOURCE_SCOPES entry, no fetcher, no lister. on: integration <fqn> crashed with KeyError: ResourceType.INTEGRATION. Fixed: register AccountScope(); add fetch_integration (walks SHOW INTEGRATIONS) and list_integrations. No concrete Integration resource class — declarative management still goes through the specific subtypes (APIIntegration, CatalogIntegration, etc.). The umbrella exists solely to let on: integration <fqn> parse and resolve.
• fetch_api_integration crashed with KeyError: 'api_aws_role_arn' on non-AWS-Gateway API integrations (GIT_HTTPS_API, AZURE_API_MANAGEMENT, GOOGLE_API_GATEWAY). Fixed: ApiProvider enum expanded, _APIIntegration has optional azure_tenant_id/azure_ad_application_id/google_audience, and api_aws_role_arn is now optional. fetch_api_integration uses .get() so absent fields fall back to None instead of crashing.

Example usage

api_integrations:
  - name: github_api_integration
    api_provider: GIT_HTTPS_API
    api_allowed_prefixes: ["https://github.com/some-org/"]
    enabled: true

git_repositories:
  - name: dbt_platform_repo
    database: db_dev
    schema: public
    origin: https://github.com/some-org/some-repo.git
    api_integration: github_api_integration
    git_credentials: github_secret
    comment: dbt platform repo

grants:
  - priv: READ
    on:
      - git repository db_dev.public.dbt_platform_repo
      - git repository db_prod.public.dbt_platform_repo
    to: dbt_runner
  - priv: USAGE
    on: integration github_api_integration   # umbrella also works
    to: dbt_developer

Tests

pytest tests/ --ignore=tests/integration → 1492 passed.

Integration tests (real Snowflake) require credentials; covered behind pytest.mark.requires_snowflake.

Notes for review

• Out of scope intentionally: ALTER GIT REPOSITORY ... FETCH orchestration. Snowcap is state-shape; FETCH is a runtime op.
• The git_credentials prop uses IdentifierProp (matches DESC GIT REPOSITORY returning a fully-qualified secret identifier).
• Both (2) and (3) are independent improvements that I'd happily split out into separate PRs if you prefer; folding them here because each gap surfaced while exercising the GitRepository feature in real YAML.

🤖 Generated with Claude Code

[noel]

Thanks for this contribution! This is a well-structured PR with comprehensive test coverage and documentation.

All tests pass (1492) and linting is clean. Merging now.