Request: deprecate io.github.traffiycom-ui/paidsync (all versions), publisher locked out after GitHub account rename, freed handle is unclaimed

Summary

I'm the original publisher of io.github.traffiycom-ui/paidsync. That GitHub account has since been renamed traffiycom-ui to traffiy, so a fresh mcp-publisher login github now grants only io.github.traffiy/* and org namespaces, never io.github.traffiycom-ui/*. A PATCH /v0/servers/io.github.traffiycom-ui%2Fpaidsync/status with my current registry JWT returns 403, as expected.

Affected entry (verified 2026-09-01)

Server name	Version	Status	Remote
io.github.traffiycom-ui/paidsync	1.0.0 (latest)	active	sse at https://mcp.paidsync.ai/sse

The remote is dead: https://mcp.paidsync.ai/sse returns 404 (the SSE transport was retired). The live, maintained entry for the same product is io.github.PaidSync/paidsync (v2.1.0, streamable-http at https://mcp.paidsync.ai/mcp), published from the PaidSync org which my current account administers.

Request

Set io.github.traffiycom-ui/paidsync, all versions, to deprecated (or deleted at your discretion), with a statusMessage like "Superseded by io.github.PaidSync/paidsync".

Proof of control

The orphaned entry's remote URL is on paidsync.ai, which I control. Happy to prove that any way you like: a DNS TXT record on paidsync.ai or a well-known file at any path you name, containing any challenge string you choose. The canonical io.github.PaidSync/paidsync entry already serves the same live mcp.paidsync.ai endpoint from the same infrastructure.

Security note, why this is more than housekeeping

The freed handle traffiycom-ui is currently unclaimed (https://github.com/traffiycom-ui returns 404). As raised in the comments of #1388, anyone who registers that handle inherits publish rights over io.github.traffiycom-ui/* and could republish this "paidsync" entry with an arbitrary remote URL, impersonating a live commercial MCP endpoint that handles ad-account OAuth. Deprecating or deleting the existing entry narrows that impersonation surface while the underlying login-string-vs-numeric-ID ownership question is open.

I'm aware of the rename-back workaround suggested in #1388 and can fall back to it in a maintenance window, but would prefer not to rename a production account if a maintainer-side status change is possible here.