fix(api): normalize + truncate commitMessage to 255 chars to prevent varchar(255) DB error

[darknessomi]

Description

Fix an upload/rollback failure caused by overly long commitMessage values being written into releases.commit_message (varchar(255)), which triggered the database error: value too long for type character varying(255).
The API now normalizes whitespace and safely truncates commitMessage to 255 Unicode characters before creating a release record.

DB error:
Upload error: error: value too long for type character varying(255) at async h.createRelease (.next/server/pages/api/tracking/[release_id].js:26:96) at async q (.next/server/pages/api/upload.js:33:8799) at async Module.m (.next/server/pages/api/upload.js:33:12170) { length: 99, severity: 'ERROR', code: '22001', detail: undefined, hint: undefined, position: undefined, internalPosition: undefined, internalQuery: undefined, where: undefined, schema: undefined, table: undefined, column: undefined, dataType: undefined, constraint: undefined, file: 'varchar.c', line: '632', routine: 'varchar' }

Type of change

• Bug fix (non-breaking change which fixes an issue)

For Bug Fixes

Describe the bug

When the git commit message is long (e.g., multi-line body or >255 characters), the upload flow passes it through and the backend attempts to store it in releases.commit_message (limited to 255 chars), causing the DB insert to fail and the request to error.

Steps to reproduce

1. Create a git commit with a long message (multi-line and/or >255 characters)
2. Run the upload flow (POST /api/upload with commitMessage)
3. Observe the database error: value too long for type character varying(255)

Expected behavior

Upload/rollback succeeds and a release record is created even if the commit message is long.

Actual behavior

The DB insert fails due to commit_message exceeding varchar(255), causing upload/rollback to fail.

Testing

• npm test (Jest): all tests passed (6 suites / 24 tests / 17 snapshots)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective