#1479 Extensions without a repository can't receive issues — including the issue asking them to add one

Problem

swamp issue <type> --extension <name> refuses when the target extension declares no repository: field:

$ swamp issue feature --extension @adam/cfgmgmt --title "..." --body "..."
{
  "status": "refused",
  "reason": "no-repository",
  "guidance": "The extension `@adam/cfgmgmt` does not declare a repository URL,
               so swamp can't route reports anywhere."
}

This is circular. The report we were trying to file was "please declare a licence and a repository" — and the missing repository is precisely what prevents it being delivered. An extension with no repository is unreportable by construction, and the gap is self-sealing: no channel exists to ask for the thing whose absence closes the channel.

Why it matters

@adam/cfgmgmt publishes 36 model types that run as root over SSH across a fleet. It ships no LICENSE and declares no repository, so a consumer:

• cannot legally vendor a copy for disaster recovery (default copyright applies)
• cannot diff versions before upgrading something that runs as root
• cannot file an issue asking for either to be fixed

The extension is otherwise good — a focused review of the published bundle found no network egress, no dynamic code, correct POSIX shell escaping applied consistently, sudo passwords passed via stdin rather than argv, and sensitive fields marked. We wanted to build on it and could not, on provenance grounds alone.

Notably, the quality rubric already scores has-license (1 pt) and repository-verified (2 pts), so the platform clearly considers both desirable — yet neither is required to publish, and their absence disables the feedback path that might otherwise correct it.

Suggested fix

Any one of these breaks the loop:

1. Fall back to the publisher's swamp-club account when no repository is declared — file it as a Lab issue tagged with the extension, as already happens for @swamp/*. The publisher has an account; the report has somewhere to go.
2. Allow --email to work in this case, pre-filling the publisher's contact address rather than refusing outright.
3. Require repository: at push time, so the situation cannot arise. The most decisive option, though it would break existing publishers.

(1) seems the smallest change with the best outcome, and it makes the routing guarantee unconditional: every published extension can receive a report.

Secondary suggestion

swamp extension search output does not include licence, repository, or quality score, so provenance problems are only discoverable by running swamp extension info --json per candidate, or by pulling and inspecting the archive. Surfacing license and repositoryVerified in search results — or supporting a filter on them — would let consumers apply a provenance bar before pulling anything.

Current workaround

Contact the publisher manually via https://swamp-club.com/extensions/@adam/cfgmgmt, which the refusal message helpfully points to. It works, but it is outside the tooling and leaves no trackable record.