Fix split database metadata reads

[abnegate]

What

• read Appwrite table, attribute, and index metadata through the database-specific connection
• keep project DB reads scoped to the top-level databases collection
• add a regression test for DocumentsDB report counting with split database metadata

Why

Cloud backup export workers on DB 6 can resolve a DocumentsDB database from the project DB, but the table metadata lives in the database-specific connection. Reading database_<sequence>, attributes, or indexes from the project DB leaves migration exports stuck/failing with Collection not found.

Tests

• composer lint
• composer check
• vendor/bin/phpunit --configuration phpunit.xml tests/Migration/Unit/Sources/AppwriteDatabaseReaderTest.php
• docker compose exec tests php vendor/bin/phpunit

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[greptile-apps]

Greptile Summary

This PR fixes cloud backup export failures for DocumentsDB databases by routing reads of database_<sequence>, attributes, and indexes collections through the database-specific connection (via getDatabase()) rather than dbForProject in listTables, listColumns, listIndexes, listRows, getRow, and countResources. A new unit test verifies that dbForProject->count is never called during a DocumentsDB report.

• countResources now accepts an optional UtopiaDocument $database parameter and delegates to the correct connection, matching the pattern already used for row-table reads.
• The queryCursorAfter method — which builds pagination cursors for TableResource, CollectionResource, ColumnResource, and IndexResource — was not updated and still reads database_<n>, attributes, and indexes directly from dbForProject, leaving paginated reads over those same collections broken in split-database setups.

Confidence Score: 3/5

The fix is incomplete: queryCursorAfter still reads split-metadata collections from the project connection, so paginated exports over DocumentsDB tables, attributes, or indexes will fail the same way the PR intends to prevent.

The changes to listTables, listColumns, listIndexes, listRows, getRow, and countResources are correct and well-tested, but queryCursorAfter was missed. It still issues getDocument calls against dbForProject for database_<sequence>, attributes, and indexes — the exact collections that were moved to the database-specific connection. Any export that pages through more than one page of collections, attributes, or indexes for a DocumentsDB database will hit the same "Collection not found" error this PR set out to resolve.

src/Migration/Sources/Appwrite/Reader/Database.php — specifically the queryCursorAfter method around line 459.

Important Files Changed

Filename	Overview
src/Migration/Sources/Appwrite/Reader/Database.php	Routes database_<n>, attributes, and indexes reads through the database-specific connection in listTables, listColumns, listIndexes, listRows, getRow, and countResources, but leaves queryCursorAfter (used for pagination cursors on those same collections) still pointing at dbForProject.
tests/Migration/Unit/Sources/AppwriteDatabaseReaderTest.php	New unit test that mocks project and database connections separately and asserts that dbForProject->count is never called for a DocumentsDB report — correctly validates the core intent of this PR.

Comments Outside Diff (1)

1. src/Migration/Sources/Appwrite/Reader/Database.php, line 459-474 (link)

   queryCursorAfter still reads split metadata from dbForProject

   queryCursorAfter resolves cursor documents for TableResource/CollectionResource by calling $this->dbForProject->getDocument('database_' . $database->getSequence(), ...), and for ColumnResource/IndexResource it calls $this->dbForProject->getDocument('attributes', ...) and $this->dbForProject->getDocument('indexes', ...). All three collections now live in the database-specific connection for DocumentsDB split setups — the same reason this PR fixes listTables, listColumns, listIndexes, and countResources. Any paginated read that reaches queryCursorAfter (e.g. listing collections, attributes, or indexes beyond the first page) will throw the same "Collection not found" that triggered this fix.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "fix: read split database metadata from d..." | Re-trigger Greptile}