Add an Airtable service configuration

[shreyanshjain7174]

What

Add Airtable as a registered service, following the exact pattern already used by github, slack, stripe, and google_workspace.

Why

More service configurations mean more agents can use AgentGate out of the box without writing any Go code — this is a config-only, no-code-required contribution.

Files to touch

• configs/services.yaml — the file the Dockerfile and quickstart actually load. Add an airtable: entry.
• config/services.yaml — the local, non-Docker dev default. Add the same entry for consistency (see internal/registry/production_config_test.go's TestProductionConfig_LocalDevDefaultMatches, which checks these two files don't drift).
• configs/services/airtable.yaml — a new per-service reference file, matching the convention README.md points readers at (see configs/services/google_workspace.yaml for the exact shape to copy).

Suggested shape

Airtable's REST API (https://airtable.com/developers/web/api/introduction) uses Bearer personal access tokens and takes the base ID and table name as path segments:

airtable:
  base_url: https://api.airtable.com
  auth:
    type: bearer
  actions:
    list_records:
      method: GET
      path: /v0/{base_id}/{table_name}
      params:
        base_id: string
        table_name: string
        maxRecords: "int?"

Acceptance checks

• configs/services.yaml, config/services.yaml, and configs/services/airtable.yaml all parse as valid YAML and match the registry.Config schema in internal/registry/registry.go.
• go test ./internal/registry/... passes, including the existing TestProductionConfig_* tests.
• No Go code changes are required for this issue.

Test path (no secrets needed)

go test ./internal/registry/... -run TestProductionConfig -v

This test loads the real config files directly — no live Airtable account, API key, or network access needed.