#273 extension pull fails on @local/[email protected] phantom-claim collision when local repo has its own extension

Summary

swamp extension pull <pkg> --force fails with a Type ... is already claimed error involving a phantom @local/[email protected] extension (note the empty middle segment), even when the target package being pulled is unrelated to any local extension. The collision blocks installation of any new registry extension into a swamp repo that already has its own local extension manifest.

Environment

• swamp version: 20260506.233640.0-sha.5729ac50
• OS: macOS (Darwin 25.4.0)
• Local repo: hivemq-terraform-harvester
• Local extension manifest: extensions/manifest.yaml declares name: "@hivemq/terraform-harvester", version: "2026.04.21.1", with reports including reports/cve_2026_31431_patch_status.ts.

Steps to reproduce

1. Have a swamp repo with a local extension whose manifest claims one or more report types (e.g. @hivemq/cve-2026-31431-patch-status).
2. Confirm the registered local extension via swamp extension list (in our case the catalog has it as @local/[email protected], despite the manifest declaring @hivemq/[email protected] — already a separate divergence symptom).
3. Run swamp extension pull @keeb/ssh --force.

Actual

The pull aborts with:

WRN swamp·persistence·extension-repository Dropping orphan row at ".../pulled-extensions/@hivemq/harvester/kubeconfig/models/harvester/kubeconfig.ts": source path matches no known extension layout.
WRN swamp·persistence·extension-repository Dropping orphan row at ".../pulled-extensions/@hivemq/harvester/kubevirt/models/harvester/kubevirt.ts": source path matches no known extension layout.
WRN swamp·persistence·extension-repository Dropping orphan row at ".../pulled-extensions/@hivemq/honeycomb/models/honeycomb/honeycomb.ts": source path matches no known extension layout.
WRN swamp·persistence·extension-repository Dropping orphan row at ".../pulled-extensions/@hivemq/jenkins/models/jenkins.ts": source path matches no known extension layout.
FTL error Error: 'Type "@hivemq/cve-2026-31431-patch-status" (kind=report) is already claimed by @local/[email protected] at /Users/blake.irvin/hivemq/hivemq-terraform-harvester/extensions/reports/cve_2026_31431_patch_status.ts. Cannot install @local/[email protected] at /workspace/extensions/reports/cve_2026_31431_patch_status.ts — filesystem changes rolled back. Run `swamp extension rm @local/hivemq-terraform-harvester` first if you intended to replace it.'

Expected

swamp extension pull @keeb/ssh --force should pull @keeb/ssh without re-installing or re-validating unrelated local extensions. The local extension is not being modified; nothing in the pulled bundle conflicts with @hivemq/cve-2026-31431-patch-status.

Observations / hypothesis

1. The conflict is between two records of the same local extension, not between a registry extension and a local one:
   • Existing claim: @local/[email protected] at /Users/blake.irvin/.../extensions/reports/cve_2026_31431_patch_status.ts
   • Attempted install: @local/[email protected] at /workspace/extensions/reports/cve_2026_31431_patch_status.ts
2. The @local/[email protected] name (empty middle segment) and /workspace/... path strongly suggest a containerized swamp subprocess re-scans the local repo via a different mount path and produces a different registration name (no name field, falling back to .). The host registration uses the manifest name hivemq-terraform-harvester but @0.0.0 rather than the manifest version 2026.04.21.1 — also unexpected.
3. The "Dropping orphan row" warnings show the pull also revisits already-installed @hivemq/* extensions, which is unnecessary work for an unrelated @keeb/ssh pull.
4. The suggested workaround (swamp extension rm @local/hivemq-terraform-harvester) is destructive in a repo that depends on its local extension.

Workaround

In our case we sidestepped the pull entirely and used command/shell for the one-off task we wanted @keeb/ssh for. But this means contributors to a repo with local extensions cannot easily add new registry extensions on top.

Asks

• Make extension pull of a registry package idempotent w.r.t. unrelated local extensions — do not re-install/re-claim them.
• Investigate why the host catalog records the local extension as @local/[email protected] instead of the manifest values (@hivemq/[email protected]).
• Investigate why a containerized re-scan of the same repo yields a different identity (@local/[email protected]).