Restore v0.23.0 documentation updates

Re-applies the documentation changes from PR #759 (reverted in 8406977)
that cover the upstream toolhive v0.23.0 release:

- Add v0.23.0 section to the v1beta1 migration guide covering the CRD
  API graduation from v1alpha1 to v1beta1.
- Document the default callback URL for MCPExternalAuthConfig upstream
  providers in the Kubernetes auth guide.
- Bump apiVersion to toolhive.stacklok.dev/v1beta1 across manifest
  examples in guides, integrations, and tutorials.

Auto-generated CRD reference assets were already refreshed in 4ac41c0
and are not re-applied here.

Author: claude[bot]

docs/toolhive/guides-cli/build-containers.mdx

@@ -101,7 +101,7 @@ thv build --tag mcp-servers/git-server:stable uvx://mcp-server-git
 Use the built image in your Kubernetes manifests:
 
 ```yaml
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: git-server
@@ -263,7 +263,7 @@ you need to pre-build containers before deploying them.
 3. **Deploy to Kubernetes** using the pre-built image:
 
    ```yaml
-   apiVersion: toolhive.stacklok.dev/v1alpha1
+   apiVersion: toolhive.stacklok.dev/v1beta1
    kind: MCPServer
    metadata:
      name: git-server

docs/toolhive/guides-k8s/auth-k8s.mdx

@@ -107,7 +107,7 @@ isolation.
 <TabItem value="inline" label="External IdP" default>
 
 ```yaml title="shared-oidc-config.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPOIDCConfig
 metadata:
   name: production-oidc
@@ -127,7 +127,7 @@ spec:
 <TabItem value="k8s" label="Kubernetes service account">
 
 ```yaml title="k8s-oidc-config.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPOIDCConfig
 metadata:
   name: k8s-sa-oidc
@@ -154,7 +154,7 @@ Use `oidcConfigRef` instead of inline `oidcConfig`. Each server must set a
 unique `audience` to prevent token replay across servers:
 
 ```yaml title="mcp-server-shared-oidc.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: weather-server
@@ -217,7 +217,7 @@ settings, and an `MCPServer` resource that references it. The ToolHive proxy
 handles authentication before forwarding requests to the MCP server.
 
 ```yaml title="mcp-server-external-auth.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPOIDCConfig
 metadata:
   name: external-oidc
@@ -229,7 +229,7 @@ spec:
     clientId: 'your-client-id'
     jwksUrl: 'https://your-oidc-issuer.com/path/to/jwks'
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: weather-server-external
@@ -310,7 +310,7 @@ Create an `MCPOIDCConfig` resource for Kubernetes service account authentication
 and an `MCPServer` that references it:
 
 ```yaml title="mcp-server-k8s-auth.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPOIDCConfig
 metadata:
   name: k8s-sa-oidc
@@ -321,7 +321,7 @@ spec:
     serviceAccount: 'mcp-client'
     namespace: 'client-apps'
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: weather-server-k8s
@@ -499,7 +499,7 @@ Create an `MCPExternalAuthConfig` resource with the `embeddedAuthServer` type.
 This example configures an OIDC upstream provider (the most common case):
 
 ```yaml title="embedded-auth-config.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPExternalAuthConfig
 metadata:
   name: embedded-auth-server
@@ -562,7 +562,7 @@ authorization server itself. The MCPOIDCConfig issuer must match the `issuer` in
 your `MCPExternalAuthConfig`.
 
 ```yaml title="mcp-server-embedded-auth.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPOIDCConfig
 metadata:
   name: embedded-auth-oidc
@@ -573,7 +573,7 @@ spec:
     # This must match the embedded authorization server issuer url
     issuer: 'https://mcp.example.com'
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: weather-server-embedded
@@ -690,7 +690,7 @@ for providers like GitHub that use OAuth 2.0 but don't implement the full OIDC
 specification.
 
 ```yaml title="embedded-auth-oauth2-config.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPExternalAuthConfig
 metadata:
   name: embedded-auth-oauth2
@@ -788,6 +788,51 @@ refresh-token state), add `prompt: 'consent'` alongside `access_type: 'offline'`
 - Google then shows the consent screen on every login and re-issues a refresh
   token each time.
 
+### Default callback URL for upstream providers
+
+When you omit `redirectUri` from an upstream provider's `oidcConfig` or
+`oauth2Config`, the operator defaults it to `{resourceUrl}/oauth/callback`.
+`resourceUrl` is the `oidcConfigRef.resourceUrl` set on the MCPServer or
+VirtualMCPServer that references this MCPExternalAuthConfig. It's typically the
+external URL that MCP clients use to reach the server.
+
+You still need to register this callback URL with your upstream OAuth2 or OIDC
+provider before the flow can complete. Use the same URL on both sides: the value
+computed from `resourceUrl` here, and the authorized redirect URI in your
+provider's application settings.
+
+For example, given this `oidcConfigRef` on an MCPServer:
+
+```yaml
+spec:
+  oidcConfigRef:
+    name: embedded-auth-oidc
+    audience: 'https://mcp.example.com/mcp'
+    resourceUrl: 'https://mcp.example.com/mcp'
+```
+
+Omitting `redirectUri` on the upstream provider resolves the callback to
+`https://mcp.example.com/mcp/oauth/callback`:
+
+```yaml
+upstreamProviders:
+  - name: google
+    type: oidc
+    oidcConfig:
+      issuerUrl: 'https://accounts.google.com'
+      clientId: '<YOUR_GOOGLE_CLIENT_ID>'
+      clientSecretRef:
+        name: upstream-idp-secret
+        key: client-secret
+      # redirectUri omitted - defaults to:
+      # https://mcp.example.com/mcp/oauth/callback
+```
+
+Set `redirectUri` explicitly if you need a non-default callback path, for
+example to route the callback through a separate gateway hostname. If
+`resourceUrl` is also unset, no default is applied and the upstream provider
+must have `redirectUri` set explicitly.
+
 ## Set up authorization
 
 All authentication approaches can use the same authorization configuration using
@@ -836,7 +881,7 @@ kubectl apply -f authz-configmap.yaml
 Add the authorization configuration to your `MCPServer` resources:
 
 ```yaml title="mcp-server-with-authz.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPOIDCConfig
 metadata:
   name: k8s-sa-authz-oidc
@@ -847,7 +892,7 @@ spec:
     serviceAccount: 'mcp-client'
     namespace: 'client-apps'
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: weather-server-with-authz

docs/toolhive/guides-k8s/connect-clients.mdx

@@ -105,7 +105,7 @@ First, ensure you have an MCP server deployed. This example uses the `fetch`
 server:
 
 ```yaml title="fetch-server.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: fetch
@@ -235,7 +235,7 @@ First, in the MCPServer spec for each server, ensure the `resourceUrl` property
 is set to the full client-facing URL via `oidcConfigRef`:
 
 ```yaml title="fetch-server-oauth.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 # ...
 spec:
@@ -493,7 +493,7 @@ First, in the MCPServer spec for each server, ensure the `resourceUrl` property
 is set to the full client-facing URL via `oidcConfigRef`:
 
 ```yaml title="fetch-server-oauth.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 # ...
 spec:

docs/toolhive/guides-k8s/customize-tools.mdx

@@ -23,7 +23,7 @@ descriptions. You reference the configuration from an MCPServer using the
 This example exposes only three tools on a server:
 
 ```yaml title="toolconfig-basic.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPToolConfig
 metadata:
   name: basic-tool-filter
@@ -51,7 +51,7 @@ scopes (for example, separate GitHub orgs, repos, or environments). Renaming
 tools makes intent obvious and helps prevent mistakes.
 
 ```yaml title="toolconfig-with-overrides.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPToolConfig
 metadata:
   name: github-tools-config
@@ -112,7 +112,7 @@ resource.
 <TabItem value="mcpserver" label="MCPServer" default>
 
 ```yaml {10-11} title="mcpserver-with-toolconfig.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: github
@@ -130,7 +130,7 @@ spec:
 <TabItem value="mcpremoteproxy" label="MCPRemoteProxy">
 
 ```yaml {10-11} title="mcpremoteproxy-with-toolconfig.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPRemoteProxy
 metadata:
   name: github
@@ -161,7 +161,7 @@ Run the GitHub MCP twice, once per organization, and rename tools so intent is
 clear to clients.
 
 ```yaml title="github-org-scoped-tools.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPToolConfig
 metadata:
   name: github-acme-tools
@@ -176,7 +176,7 @@ spec:
     get_pull_request:
       name: github_acme_get_pr
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPToolConfig
 metadata:
   name: github-foocorp-tools
@@ -191,7 +191,7 @@ spec:
     get_pull_request:
       name: github_foocorp_get_pr
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: github-acme
@@ -204,7 +204,7 @@ spec:
   toolConfigRef:
     name: github-acme-tools
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: github-foocorp

docs/toolhive/guides-k8s/logging.mdx

@@ -84,7 +84,7 @@ your MCP server manifest:
 <TabItem value="mcpserver" label="MCPServer" default>
 
 ```yaml {11-12}
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServer
 metadata:
   name: <SERVER_NAME>
@@ -102,7 +102,7 @@ spec:
 <TabItem value="mcpremoteproxy" label="MCPRemoteProxy">
 
 ```yaml {11-12}
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPRemoteProxy
 metadata:
   name: <SERVER_NAME>
@@ -120,7 +120,7 @@ spec:
 <TabItem value="virtualmcpserver" label="VirtualMCPServer">
 
 ```yaml {11-14}
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: VirtualMCPServer
 metadata:
   name: <SERVER_NAME>

docs/toolhive/guides-k8s/mcp-server-entry.mdx

@@ -79,7 +79,7 @@ MCPServerEntry resources must be part of an MCPGroup. Create the group first if
 it doesn't exist:
 
 ```yaml title="my-group.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPGroup
 metadata:
   name: my-group
@@ -91,7 +91,7 @@ spec:
 Then create a basic MCPServerEntry:
 
 ```yaml title="my-entry.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServerEntry
 metadata:
   name: my-remote-tool
@@ -142,7 +142,7 @@ exchange. The MCPExternalAuthConfig must exist in the same namespace as the
 MCPServerEntry.
 
 ```yaml title="auth-entry.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPExternalAuthConfig
 metadata:
   name: my-auth-config
@@ -157,7 +157,7 @@ spec:
       key: client-secret
     audience: https://mcp.example.com
 ---
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServerEntry
 metadata:
   name: internal-tool
@@ -191,7 +191,7 @@ kubectl create configmap internal-ca-bundle \
 Then reference it in the MCPServerEntry:
 
 ```yaml title="tls-entry.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServerEntry
 metadata:
   name: internal-tool
@@ -216,7 +216,7 @@ keys, or other purposes. Use the `headerForward` field to inject headers into
 requests forwarded to the remote server.
 
 ```yaml title="header-entry.yaml"
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServerEntry
 metadata:
   name: my-remote-tool
@@ -246,7 +246,7 @@ it must already exist or be created separately:
 ```yaml title="complete-entry.yaml"
 ---
 # 1. Create the MCPGroup
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPGroup
 metadata:
   name: engineering-tools
@@ -256,7 +256,7 @@ spec:
 
 ---
 # 2. Create authentication config for token exchange
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPExternalAuthConfig
 metadata:
   name: remote-auth
@@ -273,7 +273,7 @@ spec:
 
 ---
 # 3. Create the MCPServerEntry
-apiVersion: toolhive.stacklok.dev/v1alpha1
+apiVersion: toolhive.stacklok.dev/v1beta1
 kind: MCPServerEntry
 metadata:
   name: partner-tools