Separate agent and ci_system properties (#142)

## Summary

- **Separate `agent` and `ci_system` telemetry fields**: Previously a
single `agent` property held both AI agent names and CI system names,
making them mutually exclusive. Now `agent` and `ci_system` are
independent fields — both populate when an agent runs inside CI (e.g.
Claude Code in GitHub Actions).
- **Simplify `context` field**: Now only reflects terminal type
(`interactive` / `non-interactive`), no longer duplicates agent/CI info
with `agent` or `ci` values.
- **Disable telemetry in all tests**: Added root `tests/conftest.py`
that sets `AF_TELEMETRY_DISABLED=1` so no test suite fires real
telemetry events.

## Example event shape

```json
{
  "context": "non-interactive",
  "agent": "claude-code",
  "ci_system": "github-actions",
  "command": "dags list",
  ...
}
```

---------

Co-authored-by: Claude Opus 4.6 <[email protected]>

Implement AF_READ_ONLY Mode to Block Write Operations (#138)

This PR introduces a read-only safety guard for `astro-airflow-mcp`. It
allows users and agents to safely interact with Airflow environments by
restricting the client to read-only (`GET`) requests.

## Key Changes
* **Environment Variable Guard:** When `AF_READ_ONLY` is set to 'true',
any state-mutating API calls (`POST`, `PATCH`, `PUT`, `DELETE`) are
blocked automatically at the adapter request layer.
* **Informative Errors:** Attempted writes trigger a ReadOnlyError,
which returns a clear message detailing the blocked operation and active
environment variable to the user/agent.
* **Guarded Toolset:** Core actions like `pause_dag`, `unpause_dag`,
`trigger_dag_run`, and `clear_task_instances` successfully respect this
flag and will surface the rejection context without executing against
Airflow.
* **Testing:** Added robust unit and E2E coverage in
`tests/test_read_only.py` to ensure read commands (`list_dags`, etc.)
still succeed, and all writes are properly intercepted and verified.

Bump plugin version to 0.2.0

Reflects accumulated changes since 0.1.0:
- 20+ skills added/updated (Cosmos, Airflow HITL, lineage annotation, etc.)
- Hook improvements
- af CLI integration
- Multi-database support

Skill: Cosmos (#96)

New skills added: 
- **cosmos-dbt-core**: Cosmos + dbt Core implementation covering parsing
strategies, execution modes, warehouse connections, and testing behavior
- **cosmos-dbt-fusion**: Cosmos + dbt Fusion (Snowflake/Databricks only,
LOCAL execution mode)

feat(cli): Add `af api` command for direct Airflow REST API access (#73)

## Summary

Add a generic `af api` command that provides direct access to any
Airflow REST API endpoint, similar to `gh api` for GitHub. This enables
users and AI agents to access any API endpoint not covered by the
high-level CLI commands.

## Features

- **HTTP Methods**: GET, POST, PATCH, PUT, DELETE via `-X` flag
- **Query Parameters**: `-F key=value` (auto type conversion) or `-f
key=value` (raw string)
- **JSON Body**: `--body '{...}'` for complex payloads
- **Endpoint Discovery**: `--endpoints` lists available paths,
`--filter` narrows results
- **OpenAPI Spec**: `--spec` fetches full API spec
- **Response Headers**: `-i` includes status code and headers
- **Raw Endpoints**: `--raw` bypasses version prefix (for `/health`,
etc.)
- **Version Handling**: Automatic AF2 (`/api/v1`) vs AF3 (`/api/v2`)
detection

## Usage Examples

```bash
# Discover available endpoints
af api --endpoints
af api --endpoints --filter variable

# Basic operations
af api dags
af api dags -F limit=10 -F only_active=true
af api dags/my_dag

# Create/modify resources
af api variables -X POST -F key=my_var -f value="my value"
af api dags/my_dag -X PATCH -F is_paused=false
af api variables/old_var -X DELETE

# Debug with headers
af api dags -i

# Access non-versioned endpoints
af api health --raw
```

## Design Decisions

**Why add to adapter vs direct HTTP?**
The adapter pattern already handles authentication (token/basic auth via
`_setup_auth()`) and version prefixes. Adding `raw_request()` to the
base adapter keeps the architecture consistent.

**Why `--endpoints` instead of requiring jq?**
Not all users have jq installed, and endpoint discovery is a common
operation. The `--filter` option makes it easy to find specific
endpoints without external tools.

**Why warn on connections endpoint?**
Unlike `af config connections` which filters passwords, `af api
connections` returns raw API responses. The warning directs users to the
filtered alternative.

## Files Changed

| File | Change |
|------|--------|
| `adapters/base.py` | Add `raw_request()` and `_delete()` methods |
| `cli/api.py` | New command module (357 lines) |
| `cli/main.py` | Register the command |
| `tests/test_cli_api.py` | Unit tests (34 tests) |
| `tests/integration/test_cli_api.py` | Integration tests (17 tests) |
| `README.md` | Document the command |
| `skills/airflow/SKILL.md` | Add quick reference |
| `skills/airflow/api-reference.md` | Full reference (progressive
disclosure) |

Fix hatch-vcs version detection in CI publish workflow

Use SETUPTOOLS_SCM_PRETEND_VERSION to set version explicitly from the
release tag, bypassing hatch-vcs git tag parsing issues. The tag_regex
configuration in raw-options wasn't being applied correctly.

- Extract version by stripping 'astro-airflow-mcp-' prefix from tag
- Pass version via SETUPTOOLS_SCM_PRETEND_VERSION env var
- Keep pyproject.toml raw-options for local development

Co-Authored-By: Claude Opus 4.5 <[email protected]>

Fix hatch-vcs to find git root from subdirectory

In a monorepo, hatch-vcs needs root=".." to find the .git directory
when building from a package subdirectory.

Co-Authored-By: Claude Opus 4.5 <[email protected]>