Allow usage of validators (and authentication checks) as a library

Is your feature request related to a problem? Please describe.
The registry contains a bunch of validators that make sure only valid entries make it into the registry:

1. Authentication: Ensure that you are authenticated to publish servers on a given namespace
2. Validation that packages and remotes match the given authentication permissions

Unfortunately, it is very hard to reuse this outside of running a full-blown registry. I would want to avoid maintaining the logic myself, because there a quite a few specifics here.

My goal is to have a small tool with which I can, given a serverName and packages/remotes locally validate if the server is valid. This tooling could be used as part of a private subregistry that is not based on this repository.

Describe the solution you'd like
For validation, I guess it might be enough to move the internal/validators package to pkg. Mostly, I'm interested in the registries validation: https://github.com/modelcontextprotocol/registry/tree/main/internal/validators

For authentication, it seems like this logic is currently tied up in the individual auth handlers (e.g. https://github.com/modelcontextprotocol/registry/blob/535941a30e92c88b5bc83ef4e951d4183ccf19db/internal/api/handlers/v0/auth/github_oidc.go#L293), making this a broader refactoring, it seems.

Describe alternatives you've considered

1. Using the validation command of the publisher: https://github.com/modelcontextprotocol/registry/blob/main/cmd/publisher/commands/validate.go – unfortunately, it uses the /validate part of a deployed registry, making this non-optimal
2. Reimplementing the relevant logic: This will soon become outdated, as other package registries are added or authentication schemes change, so I'd ideally avoid that

Start by reading internal/validators and the authentication logic in internal/api/handlers/v0/auth/github_oidc.go, then compare it with cmd/publisher/commands/validate.go. Trace which validation and authentication checks are tied to the deployed registry or individual handlers. Done means the relevant checks can be reused by an external tool or private subregistry without reimplementing registry logic.