Discovered while trying to reproduce #10848 -- when using `forgejo doctor recreate-tables` against a PostgreSQL database with multiple Forgejo schemas in it, it fails. The reason is that when querying for index and sequence information, it begins to get information from the other schemas.
```
2026/01/15 15:19:15 ...3.6.1/command_run.go:288:run() [I] PING DATABASE postgresschema
2026/01/15 15:19:15 ...igrations/base/db.go:51:func2() [I] Creating temp table: tmp_recreate__external_login_user for Bean: ExternalLoginUser
2026/01/15 15:19:15 ...igrations/base/db.go:108:func2() [I] Copying table external_login_user to temp table tmp_recreate__external_login_user
2026/01/15 15:19:15 ...igrations/base/db.go:120:func2() [I] Dropping existing table external_login_user, and renaming temp table tmp_recreate__external_login_user in its place
2026/01/15 15:19:15 cmd/doctor.go:216:func1() [E] [Error SQL Query] ALTER INDEX "external_login_user_pkey" RENAME TO "external_login_user_pkey" [] - ERROR: relation "external_login_user_pkey" does not exist (SQLSTATE 42P01)
2026/01/15 15:19:15 ...igrations/base/db.go:404:renameTable() [E] Unable to rename external_login_user_pkey to external_login_user_pkey. Error: ERROR: relation "external_login_user_pkey" does not exist (SQLSTATE 42P01)
Command error: migrate: ERROR: relation "external_login_user_pkey" does not exist (SQLSTATE 42P01)
```
This is a very niche use-case that is likely to only affect a developer using PostgreSQL and popping back to older releases often enough to keep them around in different DB schemas. I don't think it's worth an automated test, which would require creating a secondary DB schema in a specific migration test. Manually tested on my dev environment.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10854
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
