fix(schema): widen filename columns from VARCHAR(500) to TEXT

[Tet-9]

Summary

pr_files.filename, pr_files.previous_filename, and pr_file_contents.filename were defined as VARCHAR(500). Valid Git file paths can exceed 500 characters, causing Postgres to reject PR file ingestion with value too long for type character varying(500), leaving affected PRs without file metadata or scoring data.

Root Cause

The schema used a fixed VARCHAR(500) for Git file paths, but GitHub can return file paths longer than 500 characters from /pulls/:number/files. The ingestion path passes file.filename directly to the DB with no truncation or validation.

Changes

• packages/db/08_pr_files.sql: filename and previous_filename widened to TEXT
• packages/db/09_pr_file_contents.sql: filename widened to TEXT
• packages/db/26_alter_filename_to_text.sql: migration for existing deployments
• packages/das/src/entities/PrFile.entity.ts: @PrimaryColumn type explicitly set to "text"
• packages/das/src/entities/PrFileContent.entity.ts: @PrimaryColumn type explicitly set to "text"

Testing

Lint confirmed only pre-existing errors in cache.module.ts, unrelated to this change.

Fixes #134

[Tet-9]

@anderdc , you may please review this now 🫡

[anderdc]

Spot-checked the mirror: across 30,413 pr_files rows the longest filename is 147 chars and 0 rows exceed 500 (pr_file_contents is identical — max 147, 0 over 500). The >500-char path this widens the schema for has never occurred in production data, and if it ever did the impact is an isolated failed PR_FILES job for that one PR, not a service-level fault. Not worth a prod schema change against a path the data shows we've never approached. Closing.