Dual-namespace ownership: a package published under both io.github.* and a verified domain has no way to be recognized as one publisher

The case

rust-faf-mcp resolves under two ownership namespaces for the same underlying package, and they have drifted out of sync as a direct result:

• one.faf/rust-faf-mcp → v0.4.2 (current, matches crates.io's newest_version)
• io.github.Wolfe-Jam/rust-faf-mcp → v0.3.1 (stale, several releases behind)

Publishing either namespace requires a token scoped to that specific namespace; there is no way to hold both simultaneously, and no path to link the two identities as the same publisher. In practice that friction is enough that the io.github.* entry simply stopped being republished — a client resolving via that namespace sees months-old information while the domain namespace reflects reality.

What the code does

Publish auth is a single-token check against the full namespace/name string:

• internal/api/handlers/v0/publish.go:53 — jwtManager.HasPermission(input.Body.Name, auth.PermissionActionPublish, claims.Permissions)
• internal/auth/jwt.go:156-173 — HasPermission/isResourceMatch: exact/prefix match against the token's own fixed permission list, no cross-token logic
• internal/api/handlers/v0/auth/github_at.go:295-310 — GitHub OAuth grants io.github.{username}/* and io.github.{org}/* only
• internal/api/handlers/v0/auth/common.go:228,235 — DNS/HTTP verification grants {reverseDomain}/* and {reverseDomain}.* only, with no reference to any GitHub identity

Neither grant path is aware of the other. There's no explicit branch that accepts or rejects a publisher claiming two namespaces — the permission model has no field or concept representing "these two identities are the same publisher." Two namespace strings for one package are just two unrelated resources, each free to drift independently — as they now have.

What's already documented / filed

• docs/reference/api/official-registry-api.md and docs/reference/cli/commands.md document the two auth methods per namespace type, but nothing about linking identities across them or migrating a server between namespace types.
• #1106 is the closest related report — a publisher migrating fully away from io.github.* to a domain namespace, blocked by an unrelated immutable-version URL collision (redirected to #1193). Different mechanism: one-way abandonment blocked by a validation bug, not simultaneous dual-namespace publishing.
• Searched issues/discussions broadly (namespace ownership, dual token, domain verification, publisher identity, transfer/rename namespace) — found nothing describing this exact case.

Scale

Full walk of GET /v0.1/servers?version=latest just now: 23,438 total registrations, 16,342 (69.7%) io.github.*, 7,096 (30.3%) custom-domain namespaces. Anyone holding both an io.github.* history and a verified domain for the same package hits this — and, per the drift above, it doesn't just cause friction, it produces stale published data.

Question

Is a publisher meant to hold only one namespace identity per package, with no supported way to link a second one — or is cross-namespace publisher identity intended to be supported eventually? Either answer is fine; right now the behavior isn't documented either way, and the two auth paths are structurally unaware of each other in the code.

Start with internal/api/handlers/v0/publish.go, internal/auth/jwt.go, and the GitHub and DNS verification paths in internal/api/handlers/v0/auth/. Trace how namespace permissions are issued and matched, then review the cited API and CLI documentation. Done should include a decided cross-namespace ownership behavior, its implementation or explicit rejection path, and corresponding documentation or tests.