End-to-end test suite against the real Aiven API

## Problem

Unit tests (#2) mock everything and never prove the tool actually works against a real Aiven project. We need an end-to-end suite that creates real dev-tier services, runs the CLI against them, and verifies the generated artifacts actually connect.

## Scope

- `tests/e2e/`, gated behind the `e2e` pytest marker (see #2) and run only via `mise run test:e2e` -- never on every PR (see #7 for CI wiring).
- Fixtures that, per test session: create dev-tier PG, OpenSearch, ClickHouse, and Kafka services in the `jay-miller` project (region `do-nyc`, per the user's Aiven defaults) with a unique/timestamped name prefix, wait for them to reach `RUNNING`, yield connection info, then **always** tear them down in a `finally`/fixture teardown -- including on test failure -- so a crashed run doesn't leave billable services behind.
- Test scenarios:
- Convention binding (#4) picks up each real managed service correctly by type.
- `x-aiven-service` override binds to a specific one when multiple of the same type exist.
- The generated Dockerfile/env actually lets a throwaway container reach the real service (a minimal smoke check per service type -- e.g. `pg_isready`, an OpenSearch `_cluster/health`, a ClickHouse `SELECT 1`, a Kafka metadata fetch -- not a full app test).
- `depends_on` ordering (#6) end-to-end with one local + one Aiven-managed dependency.
- Never print or log the real connection string/credentials (mask in any assertion failure messages too).
- Skip cleanly (not fail) when `AIVEN_API_TOKEN` isn't set, with a message pointing at `mise run test:e2e` / `fnox set AIVEN_API_TOKEN`.

## Acceptance criteria

- [ ] `mise run test:e2e` against the `jay-miller` project creates, exercises, and tears down all four service types with no leaked services on success or failure (verified by listing services before/after).
- [ ] No credential value appears in any test output, log, or assertion message.
- [ ] Suite is skipped, not failed, when credentials are absent.

Depends on #5 (service binding) and #6 (depends_on ordering) being implemented; depends on #4 (mise/fnox) for the `test:e2e` task and secret wiring.

Start in tests/e2e/ and inspect the pytest e2e marker and the mise run test:e2e entry point. Run the suite with AIVEN_API_TOKEN configured through fnox, then verify all four service types are exercised, credentials stay masked, missing credentials skip cleanly, and services are removed after success or failure.

Written by the indexing model from the issue text.