#427 Add extension transfer between collectives

Problem

When an extension needs to change ownership — an author goes inactive, a community extension gets adopted as official, or swamp seeds an extension and hands it to a collective — the only option today is yank-and-republish under the new namespace. This breaks the extension's identity: existing workflow references, data history, and documentation all point to the old name. Users must manually find and update everything.

Proposed Solution

Add a swamp extension transfer command that moves an extension from one collective/owner to another while preserving continuity.

swamp extension transfer @sergey/libvirt --to @bad-at-naming

Key behaviors:

• The extension is re-homed under the new collective's namespace (becomes @bad-at-naming/libvirt)
• The old name acts as a redirect — swamp extension pull @sergey/libvirt resolves to @bad-at-naming/libvirt with a notice
• Existing workflow references using the old name continue to resolve (with a warning encouraging update)
• Both the source and destination collective must approve the transfer (e.g. an accept/confirm flow)
• Version history and data lineage are preserved, not reset
• Only collective owners/members can initiate or accept transfers

Use Cases

1. Community adoption: A personal extension matures and moves to a shared collective
2. Official adoption: swamp adopts a well-maintained community extension into @swamp
3. Handoff: swamp seeds an extension and transfers ownership to a community collective
4. Author transition: An author leaves or goes inactive, collective takes over maintenance

Design Considerations

• Redirect expiry: Should old-name redirects be permanent, or expire after N versions under the new name?
• Transfer vs. alias: A transfer moves ownership. This is distinct from deprecation (#425/#426), which says "stop using this, go use that" without moving identity.
• Registry impact: The registry needs to store the redirect mapping and serve it during resolution
• Conflict handling: What if the destination collective already has an extension with the same base name?

Alternatives Considered

• Yank and republish: Current workaround — breaks all existing references, loses version history
• Deprecation with superseded-by (#425): Different use case — deprecation says "use something else," transfer says "this moved"
• Aliases without transfer: Could work for resolution but doesn't solve the ownership/publishing question