Update Registry Server docs for v1.0.0 and v1.0.1

Restructure configuration docs to reflect the new two-level config
model (sources + registries), add a dedicated authorization guide
covering RBAC roles and claims-based access control, and update all
related pages for cross-document consistency.

Key changes:
- Rewrite configuration.mdx for sources/registries split
- Add authorization.mdx (roles, claims, /v1/me endpoint)
- Replace claimMapping with authz-claims annotation docs
- Document skills sync from external sources
- Document multiple Kubernetes sources support
- Add DNS subdomain naming requirement for source names
- Update cross-references across deployment, skills, and intro pages
- Fix broken anchor in remote-mcp-proxy.mdx

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: rdimitrov

docs/toolhive/contributing.mdx

@@ -70,8 +70,9 @@ actively being developed and tested.
 ### Registry server
 
 The Registry Server is an API server that implements the official MCP Registry
-API. It provides standardized access to MCP servers from multiple backends,
-including file-based and other API-compliant registries.
+API. It provides standardized access to MCP servers and skills from multiple
+backends, including Git repositories, API endpoints, files, managed sources, and
+Kubernetes clusters.
 
 **Repository**:
 [stacklok/toolhive-registry-server](https://github.com/stacklok/toolhive-registry-server)

docs/toolhive/guides-k8s/remote-mcp-proxy.mdx

@@ -801,7 +801,7 @@ Learn how to customize MCP tools using
 [filters and overrides](./customize-tools.mdx).
 
 Discover your deployed MCP servers automatically using the
-[Kubernetes registry](../guides-registry/configuration.mdx#kubernetes-registry)
+[Kubernetes source](../guides-registry/configuration.mdx#kubernetes-source)
 feature in the ToolHive Registry Server.
 
 ## Related information

docs/toolhive/guides-registry/authentication.mdx

@@ -10,6 +10,14 @@ OAuth mode to protect your registry. You can configure authentication to fit
 different deployment scenarios, from development environments to production
 deployments with enterprise identity providers.
 
+:::tip[Looking for authorization?]
+
+This page covers **authentication** (verifying caller identity). For
+**authorization** (controlling what callers can do), including role-based access
+control and claims-based scoping, see [Authorization](./authorization.mdx).
+
+:::
+
 ## Authentication modes
 
 The server supports two authentication modes configured via the required `auth`
@@ -349,6 +357,7 @@ regardless of the auth mode:
 - `/health` - Health check endpoint
 - `/readiness` - Readiness probe endpoint
 - `/version` - Version information
+- `/openapi.json` - OpenAPI specification
 - `/.well-known/*` - OAuth discovery endpoints (RFC 9728)
 
 You can configure additional public paths using the `publicPaths` field in your
@@ -499,6 +508,14 @@ providers:
     caCertPath: /etc/ssl/certs/internal-ca.crt
 ```
 
+## Next steps
+
+- [Configure authorization](./authorization.mdx) to set up role-based access
+  control and claims-based scoping
+- [Set up the database](./database.mdx) for production storage and migrations
+- [Configure telemetry](./telemetry-metrics.mdx) for distributed tracing and
+  metrics collection
+
 ## Troubleshooting
 
 ### 401 Unauthorized errors
@@ -544,9 +561,3 @@ If tokens from some providers work but others don't:
 4. Review server logs to identify which specific provider validation is failing
 5. Test each provider's JWKS endpoint accessibility:
    `curl ${issuerUrl}/.well-known/openid-configuration`
-
-## Next steps
-
-- [Set up the database](./database.mdx) for production storage and migrations
-- [Configure telemetry](./telemetry-metrics.mdx) for distributed tracing and
-  metrics collection