Add `swamp extension yank` command

Problem

Once an extension is published to the swamp registry, there's no CLI mechanism to yank it. If a published extension is malicious, has a security vulnerability, or violates policy, there needs to be a way to remove it from availability directly from the CLI.

Companion Issue

Server-side implementation: https://github.com/systeminit/swamp-club/issues/101

Proposed Solution

Add a yank subcommand to the existing swamp extension command group that calls the registry's yank API endpoints. Authorization is enforced entirely server-side — extension owners can yank their own extensions, and admins (@systeminit.com accounts) can yank any extension.

Command Signature

swamp extension yank <extension> [version] --reason <reason>

Examples:

# Yank a specific version
swamp extension yank @acme/bad-extension 2026.03.01.1 --reason "Security vulnerability"

# Yank an entire extension (all versions)
swamp extension yank @acme/bad-extension --reason "Policy violation"

Arguments & Options

Implementation Areas

• Yank command — src/cli/commands/extension_yank.ts implementing the CLI action
• Register subcommand — Add .command("yank", extensionYankCommand) to src/cli/commands/extension.ts
• ExtensionApiClient — Add yankExtension(name, version | null, reason, apiKey) method to src/infrastructure/http/extension_api_client.ts calling:
  • POST /api/v1/extensions/{name}/yank (full extension)
  • POST /api/v1/extensions/{name}@{version}/yank (specific version)
  • Request body: { reason: string }
  • Auth: existing Bearer token from swamp auth login
• Output rendering — src/presentation/output/extension_yank_output.ts supporting both log and json modes
• Confirmation prompt — Require interactive confirmation before yanking (destructive operation), skippable with -y
• Error handling — Map HTTP status codes to user-friendly messages:
  • 401 → "Not authenticated. Run 'swamp auth login' first."
  • 403 → "You don't have permission to yank this extension."
  • 404 → "Extension or version not found."
  • 410 → "Already yanked."
• Tests — Unit tests for command argument parsing, API client method, and output rendering

Authorization Model

Authorization is enforced entirely server-side. The CLI sends the user's existing auth token with the yank request. The swamp-club backend determines permissions:

• Extension owners can yank their own extensions/versions
• Admins (@systeminit.com accounts) can yank any extension

No client-side authorization logic is needed beyond the existing swamp auth login flow.

Notes

• Follows existing patterns from extension push for auth, confirmation prompts, and output rendering
• parseExtensionRef() already handles extension name parsing
• No unyank command for now (can be done via DB per the companion issue)