[bot] sync troubleshooting guides to db (supabase#40100)

* fix(troubleshooting sync)

A few troubleshooting guides aren't syncing properly, for miscellaneous
issues:

- Misformatted link
- Edge cases with Markdown parsing:
  - GFM automatically wraps emails in angle brackets, which subsequently
breaks MDX because it expects anything wrapped in angle brackets to be a
JSX tag
  - toMarkdown inserts sentinel comments between certain blocks, which
subsequently breaks MDX for the same reason

* [bot] sync troubleshooting guides to db

* Update apps/docs/content/troubleshooting/converted-github-account-to-organisation---lost-supabase-account-access-5wsE_1.mdx

* Update apps/docs/content/troubleshooting/new-branch-doesnt-copy-database.mdx

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

---------

Co-authored-by: Charis Lam <26616127+charislam@users.noreply.github.com>
Co-authored-by: github-docs-sync-bot <github-docs-sync-bot@supabase.com>
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Author: 4 people

apps/docs/content/troubleshooting/converted-github-account-to-organisation---lost-supabase-account-access-5wsE_1.mdx

@@ -11,4 +11,4 @@ database_id = "94c6e33b-cc05-49b3-b010-7480f8dde843"
 
 If possible, create a new GitHub account using the **same email** as the previous GitHub account that was turned into a Organization or that was deleted. Once you sign in with that newly created account, you should have access to the old account. You can then invite any new account to have access to the Organization and Projects as needed.
 
-If that is not possible, Supabase can help you transfer ownership of an existing organization on your account by inviting a new owner to your organization. This new user will need to have a different email from the previous one, and you will need to email support@supabase.com with that new email as well to confirm that you own the email address.
+If that is not possible, Supabase can help you transfer ownership of an existing organization on your account by inviting a new owner to your organization. This new user will need to have a different email from the previous one, and you will need to email [support@supabase.com](email:support@supabase.com) with that new email as well to confirm that you own the email address.

apps/docs/content/troubleshooting/edge-function-fails-deploy.mdx

@@ -26,18 +26,13 @@ If you're not able to run the CLI or cannot identify the cause, [open a support
 
 ```
 $ supabase functions deploy FUNCTION_NAME --project-ref $PROJECT_ID
-...
-unexpected deploy status 500: {"message":"Function deploy failed due to an internal error"}
 ```
 
 **Example output with `--debug`**
 
-- From the details we can see it is exceeding the 20MB [Edge Function size limit](/docs/guides/functions/limits)
+From the details we can see it is exceeding the 20MB [Edge Function size limit](/docs/guides/functions/limits):
 
 ```
 $ supabase functions deploy FUNCTION_NAME --project-ref $PROJECT_ID --debug
-...
 Deploying Function: FUNCTION_NAME (script size: 62.61MB)
-...
-unexpected update function status 413: {"message":"request entity too large"}
 ```

apps/docs/content/troubleshooting/new-branch-doesnt-copy-database.mdx

@@ -43,12 +43,14 @@ Update remote migration history table? [Y/n]
 
 Type `Y` to update your remote project’s migration history and ensure it matches your new local migrations.
 
-- If the CLI suggests repairing migration history due to mismatches, you might see:
-  ```
-  Make sure your local git repo is up-to-date. If the error persists, try repairing the migration history table:
-  supabase migration repair --status applied <timestamp>
-  ```
-  Run the exact repair command provided, replacing the timestamp as instructed (example timestamp: 20251006141726). This synchronizes the migration state between local and remote.
+If the CLI suggests repairing migration history due to mismatches, you might see:
+
+```
+Make sure your local git repo is up-to-date. If the error persists, try repairing the migration history table:
+supabase migration repair --status applied TIMESTAMP_OF_MIGRATION_TO_REPAIR
+```
+
+Run the exact repair command provided, replacing the timestamp as instructed (example timestamp: 20251006141726). This synchronizes the migration state between local and remote.
 
 ---
 
@@ -60,4 +62,4 @@ Once your migration history is up to date, continue to use branching features as
 
 #### Additional tips
 
-- If further issues arise (such as schema drift or migration mismatches), review the [troubleshooting documentation](/docs/guides/deployment/branching/troubleshooting#migration-issues), and consider manual repair with `supabase migration repair`(https://supabase.com/docs/reference/cli/supabase-migration-repair).
+If further issues arise (such as schema drift or migration mismatches), review the [troubleshooting documentation](/docs/guides/deployment/branching/troubleshooting#migration-issues), and consider manual repair with [`supabase migration repair`](/docs/reference/cli/supabase-migration-repair).