fix(presigned-url): match files→buckets by table name prefix instead of schema name

[pyramation]

Summary

Fixes the file-upload mutation generator's files→buckets codec matching logic. The previous implementation matched by PostgreSQL schema name (extensions.pg.schemaName), which is ambiguous when multiple storage modules share the same schema. In that case, .find() returns the first bucket codec (e.g. app_buckets) for all file codecs, causing entity-scoped input types like UploadDataRoomFileInput to be missing ownerId.

The fix derives a prefix from the raw SQL table name (extensions.pg.name) by stripping the _files / _buckets suffix, then matches on that prefix:

• data_room_files → prefix data_room → matches data_room_buckets ✓
• app_files → prefix app → matches app_buckets ✓

Discovered via CI failure on constructive-db#1054: Field "ownerId" is not defined by type "UploadDataRoomFileInput".

Review & Testing Checklist for Human

• Naming convention assumption: The matching relies on tables following the <prefix>_files / <prefix>_buckets convention. Verify this holds for all current and planned storage modules. If a table name doesn't end with _files or _buckets, the replace() is a no-op and the full name becomes the prefix — could silently skip or mismatch.
• Verify with real multi-scope DB: After publishing, run the minio-multi-scope.integration.test.ts suite in constructive-db to confirm entity-scoped uploads (ownerId in UploadDataRoomFileInput) work end-to-end.
• Edge case: undefined raw name: If extensions.pg.name is somehow undefined, both filesPrefix and bucketPrefix would be undefined, causing a false match (undefined === undefined). Low risk since PostGraphile always populates this, but worth noting.

Notes

• The old schema-based matching at the same location in the bucket entry-point code (line ~180, storageBuckets loop) is not affected because bucket entry points iterate over bucket codecs directly — no cross-codec matching needed there.
• No existing unit test covers this matching logic; the plugin's test suite only has s3-signer.integration.test.ts. The real validation is the constructive-db integration test.

Link to Devin session: https://app.devin.ai/sessions/7903d2a3e7a34c6daa605e12d6b80d9e
Requested by: @pyramation

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring