#425 Add extension deprecation support to CLI

Problem

When an extension is superseded by another (e.g. a personal fork gets merged into a collective's extension), the author has no way to signal this to users. The only option today is swamp extension yank, which hard-blocks resolution and breaks existing workflows.

There's a missing middle ground: "this still works, but you should move to something else."

Proposed Solution

Add a swamp extension deprecate command that marks an entire extension (not individual versions) as deprecated in the registry.

swamp extension deprecate @jp/libvirt \
  --reason "Merged into the collective extension" \
  --superseded-by @bad-at-naming/libvirt

Key behaviors:

• Deprecated extensions remain pullable and resolvable — existing workflows don't break
• swamp extension search results show a deprecation indicator next to deprecated extensions
• swamp extension pull of a deprecated extension prints the deprecation notice and successor pointer
• swamp extension outdated surfaces deprecated extensions alongside version-outdated ones
• The --superseded-by flag is optional (an extension can be deprecated without naming a successor)
• Only the extension owner/collective members can deprecate

A corresponding swamp extension undeprecate command should reverse the state.

Context

This came out of a real experience report about the libvirt extension ecosystem. A user forked an extension, the upstream author incorporated the changes, the fork became redundant — but there was no clean way to redirect users to the canonical version.

See also: the companion swamp-club issue for displaying deprecation state on extension pages (will be linked once filed).

Alternatives Considered

• Yank only: Too aggressive — breaks existing users' workflows
• README/description update only: Easy to miss, not machine-readable, doesn't surface in CLI output
• Version-level deprecation: Wrong granularity — "use a different extension" is a project-level statement, not a release-level one