[docs] Fix broken links to '/guides/' paths (#50870)

## Problem

There are several broken links within docs that reference `/guides/...`.
These need to be updated to `/docs/guides/` to resolve correctly.

## Solution

Updated links to resolve correctly

## Preview links

If relevant, include links to changed pages for easy review access.

TBD, waiting on build (unclear if this happens for external
contributions).

## Review instructions

1. Navigate to the pages in the live/preview.
2. Click the links that were updated.

## Checklist

Check all before review:

- [x ] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Updated internal documentation links across API, Auth, Database,
Functions, and troubleshooting guides to use the `/docs` paths.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: kodster28-happy-hour <kody@catholicestateplanning.com>

apps/docs/content/guides/api/handling-errors-in-supabase-js.mdx

@@ -61,7 +61,7 @@ Database calls (`select`, `insert`, `update`, `upsert`, `delete`, `rpc`) return
 | `details` | When `hint` and `message` aren't enough. Often contains the offending value, key, or row.                          |
 | `message` | As the human summary. Useful in UI strings, less useful for debugging.                                             |
 
-A full list of PostgREST error codes is in the [Error Codes reference](/guides/api/rest/postgrest-error-codes).
+A full list of PostgREST error codes is in the [Error Codes reference](/docs/guides/api/rest/postgrest-error-codes).
 
 ## Branch on `error.code`, not `error.message`
 
@@ -140,6 +140,6 @@ supabase.channel('room1').subscribe((status, err) => {
 
 ## Related
 
-- [PostgREST Error Codes](/guides/api/rest/postgrest-error-codes)
-- [Automatic retries with `supabase-js`](/guides/api/automatic-retries-in-supabase-js)
-- [Securing your API](/guides/api/securing-your-api)
+- [PostgREST Error Codes](/docs/guides/api/rest/postgrest-error-codes)
+- [Automatic retries with `supabase-js`](/docs/guides/api/automatic-retries-in-supabase-js)
+- [Securing your API](/docs/guides/api/securing-your-api)

apps/docs/content/guides/auth/choosing-a-server-package.mdx

@@ -58,7 +58,7 @@ const supabase = createServerClient(
 )
 ```
 
-See the [server-side rendering guide](/guides/auth/server-side) for framework-specific setup.
+See the [server-side rendering guide](/docs/guides/auth/server-side) for framework-specific setup.
 
 ## `@supabase/server`
 
@@ -92,6 +92,6 @@ In a cookie-based framework you can compose the two — let `@supabase/ssr` own
 
 ## Next steps
 
-- [Server-side rendering](/guides/auth/server-side) — set up `@supabase/ssr` for your framework.
+- [Server-side rendering](/docs/guides/auth/server-side) — set up `@supabase/ssr` for your framework.
 - [`@supabase/server` reference](/docs/reference/server/introduction) — API for header-based server auth.
 - [`supabase-js` reference](/docs/reference/javascript/introduction) — the base JavaScript client.

apps/docs/content/guides/database/extensions/pg_graphql.mdx

@@ -106,7 +106,7 @@ Note that `pg_graphql` supports schema introspection, so you can connect any Gra
 comment on schema public is e'@graphql({"introspection": true})';
 ```
 
-See the [upgrade notes](/guides/platform/upgrading#upgrading-to-pg_graphql-160) for details.
+See the [upgrade notes](/docs/guides/platform/upgrading#upgrading-to-pg_graphql-160) for details.
 
 ## API
 

apps/docs/content/guides/functions/auth-headers.mdx

@@ -5,7 +5,7 @@ description: 'How the Authorization and apikey request headers and the verify_jw
 subtitle: 'How the Authorization and apikey headers and the verify_jwt platform check work'
 ---
 
-Every request to an Edge Function passes through two layers of auth. First, a platform-level check (`verify_jwt`) runs before your code executes. Then, once the request reaches your handler, you decide what to do with the credentials the caller sent. This page is the reference for both layers. For the practical patterns built on top of them, see [Securing Edge Functions](/guides/functions/auth).
+Every request to an Edge Function passes through two layers of auth. First, a platform-level check (`verify_jwt`) runs before your code executes. Then, once the request reaches your handler, you decide what to do with the credentials the caller sent. This page is the reference for both layers. For the practical patterns built on top of them, see [Securing Edge Functions](/docs/guides/functions/auth).
 
 ## Understanding authorization headers
 
@@ -41,7 +41,7 @@ For migration compatibility, `verify_jwt` accepts publishable and secret keys on
 Use the `verify_jwt` flag to match how the function is called:
 
 - **Leave `verify_jwt` on** for functions that are only called with a user JWT, such as functions invoked from the client through `supabase.functions.invoke`. The platform rejects unauthenticated requests before they reach your code, and your handler can trust that a valid JWT is present.
-- **Turn `verify_jwt` off** for functions that are called without an `Authorization` header, such as webhooks from external providers, or service-to-service calls that authenticate with an API key. These patterns are covered in [Securing Edge Functions](/guides/functions/auth).
+- **Turn `verify_jwt` off** for functions that are called without an `Authorization` header, such as webhooks from external providers, or service-to-service calls that authenticate with an API key. These patterns are covered in [Securing Edge Functions](/docs/guides/functions/auth).
 
 Set the flag per function in `supabase/config.toml`:
 

apps/docs/content/guides/functions/error-codes.mdx

@@ -174,7 +174,7 @@ export default {
 ## Authentication Errors
 
 These errors occur when the request contains a missing, malformed, or unsupported JWT token. Fixing them requires ensuring your requests include a valid authorization header, or disabling JWT verification for public endpoints.
-For further information, see [Authorization headers](/docs/guides/functions/auth-headers) and [Securing Edge Functions](/guides/functions/auth).
+For further information, see [Authorization headers](/docs/guides/functions/auth-headers) and [Securing Edge Functions](/docs/guides/functions/auth).
 
 ### UNAUTHORIZED_NO_AUTH_HEADER
 

apps/docs/content/guides/functions/examples/mcp-server-mcp-lite.mdx

@@ -278,7 +278,7 @@ When deploying MCP servers:
 - **Limit tool scope**: Only expose tools that are necessary for your use case
 - **Monitor usage**: Track tool calls and monitor for unusual activity
 
-For more security guidance, see the [MCP security guide](/guides/getting-started/mcp#security-risks).
+For more security guidance, see the [MCP security guide](/docs/guides/getting-started/mcp#security-risks).
 
 ## What's next
 
@@ -295,6 +295,6 @@ With your MCP server running on Supabase Edge Functions, you can:
 
 - [mcp-lite on GitHub](https://github.com/fiberplane/mcp-lite)
 - [Model Context Protocol Spec](https://modelcontextprotocol.io/)
-- [Supabase Edge Functions Docs](/guides/functions)
+- [Supabase Edge Functions Docs](/docs/guides/functions)
 - [Deno Runtime Documentation](https://deno.land/)
 - [Fiberplane tutorial](https://blog.fiberplane.com/blog/mcp-lite-supabase-edge-functions/)

apps/docs/content/troubleshooting/restore-project-after-90-days-pause.mdx

@@ -49,7 +49,7 @@ psql -d [CONNECTION_STRING] -f /path/to/backup_file.backup
 
 Some errors like `object already exists` are expected and can be safely ignored — they occur because the new project already has the default Supabase schemas applied.
 
-See the [Restore Dashboard backup guide](/guides/platform/migrating-within-supabase/dashboard-restore) for detailed instructions and troubleshooting.
+See the [Restore Dashboard backup guide](/docs/guides/platform/migrating-within-supabase/dashboard-restore) for detailed instructions and troubleshooting.
 
 ## Step 4: Restore Storage objects
 
@@ -284,6 +284,6 @@ The script saves both source and target configs to a local `config_sync_<timesta
 
 ## Related guides
 
-- [Migrating within Supabase](/guides/platform/migrating-within-supabase)
-- [Restore Dashboard backup](/guides/platform/migrating-within-supabase/dashboard-restore)
-- [Backup and Restore using the CLI](/guides/platform/migrating-within-supabase/backup-restore)
+- [Migrating within Supabase](/docs/guides/platform/migrating-within-supabase)
+- [Restore Dashboard backup](/docs/guides/platform/migrating-within-supabase/dashboard-restore)
+- [Backup and Restore using the CLI](/docs/guides/platform/migrating-within-supabase/backup-restore)