Add cortex_mcp_api_integration materialization

[mattsenicksigma]

Resolves #33.

Summary

• Adds a new cortex_mcp_api_integration materialization
  (macros/materializations/cortex_mcp_api_integration.sql) plus its relation
  shim (macros/relations/cortex_mcp_api_integration/), mirroring the
  existing cortex_mcp_server pattern for account-level Snowflake objects
  with no database/schema — the node is tracked internally as a view purely
  for graph/lineage; dbt never issues view DDL for it, same caveat as
  cortex_mcp_server itself already has.
• Addresses both callouts from the issue:
  1. Relation shim — same approach as cortex_mcp_server.
  2. Safer default on rebuild sweeps — defaults to
     if_not_exists=true (CREATE API INTEGRATION IF NOT EXISTS) rather than
     CREATE OR REPLACE, so a broad selector, state:modified.body sweep, or
     --full-refresh can't silently rotate a live OAuth-authenticated
     integration as a side effect. Pass if_not_exists=false explicitly to
     opt into replace-in-place semantics.
• Adds cortex_mcp_api_integration_name(ref(...)) so a cortex_mcp_server
  model's api_integration config can depend on the integration via ref()
  — a real DAG edge — instead of a bare string that has to match an object
  created out-of-band.
• Extracted the DDL-building/validation logic out of the
  create_mcp_api_integration run-operation into a shared
  _mcp_api_integration_ddl macro. Both the operation (kept, unchanged
  behavior/defaults, for one-off admin bootstrapping outside dbt build) and
  the new materialization call it, so they can't drift on DDL shape or
  validation rules.
• Found and fixed a latent, pre-existing bug while validating this against
  DuckDB: create_mcp_api_integration's dry_run branch only logged the DDL
  and never returned it, so any caller capturing the macro's rendered output
  (including the existing assert_create_mcp_api_integration_ddl integration
  test) always captured an empty string. One-line fix ({{ return(ddl) }})
  in the same file; unrelated to the materialization feature itself but
  trivial and adjacent.
• Updates the atlassian_mcp_server integration-test fixture to wire in a new
  jira_mcp_api_integration model via ref(), and extends CI to compile both
  and run the DDL-builder assertion (previously untested in CI).
• README: new cortex_mcp_api_integration section + config reference table,
  updated cortex_mcp_server bootstrap docs to present the materialization as
  the recommended path (operation kept as a documented fallback), and
  "How it works" / "Limitations & notes" entries.

Test plan

• dbt deps && dbt compile --target duckdb on the full integration-test
  project — no errors.
• dbt run --target duckdb --select jira_mcp_api_integration — config
  resolution and DDL construction verified correct (fails only at
  DuckDB's SQL parser on CREATE API INTEGRATION, which is expected —
  that DDL is Snowflake-only, same as the pre-existing cortex_mcp_server
  and cortex_skill stub materializations on non-Snowflake adapters).
• dbt run-operation assert_create_mcp_api_integration_ddl --target duckdb
  — passes after the dry_run return-value fix (previously failed with
  an empty-string capture, unrelated to this PR's feature).
• Full live-Snowflake dbt build in integration_tests/ — not run here
  (no Snowflake credentials in this environment); the DDL text and
  config-resolution logic are otherwise fully exercised above.

🤖 Generated with Claude Code