fix: Use user IDs to identify DJ profile information across auth and backend systems

[JacksonMeade]

Integrate User ID Strings with DJ System

This PR replaces the legacy numerical DJ ID system with user ID strings from the authentication database, unifying user identity across the application.

Changes

Database Migration

• Migrated all DJ ID columns from integer to varchar(255) to match user ID format
• Updated foreign key constraints to reference auth_user.id instead of the legacy djs table
• Created dj_stats table to replace DJ statistics, now keyed by user_id
• Migrated existing data by matching cognito_user_name from the old djs table to username in auth_user
• Removed orphaned records that could not be mapped to existing users
• Dropped the legacy djs table

Affected Tables

• schedule (assigned_dj_id, assigned_dj_id2)
• shift_covers (cover_dj_id)
• bins (dj_id)
• shows (primary_dj_id)
• show_djs (dj_id)

Schema Updates

• Updated Drizzle schema definitions to use varchar for all DJ ID fields
• All DJ ID references now point to user.id with appropriate cascade behaviors

Service Layer

• Updated service methods to work with user ID strings instead of integer DJ IDs
• Modified queries to join with user table instead of djs table
• Updated type definitions to reflect string-based user IDs

Migration Safety

The migration preserves existing data by:

1. Converting integer IDs to strings during column type change
2. Creating a temporary mapping table to match old DJ IDs to new user IDs
3. Updating all foreign key relationships atomically
4. Cleaning up records that cannot be mapped to valid users

Breaking Changes

• All DJ ID parameters in API endpoints now expect string values instead of integers
• Frontend clients must update to use user ID strings when referencing DJs

Test Information

• Passes all tests locally
• Bin retrieval and user information retrieval works on the frontend with edits.

[AyBruno]

Minor nit. I'd stick with wait-on in the test setup. Decreases cognitive complexity and enhances readability. Otherwise LGTM

[AyBruno]

I don't see anything wrong with keeping the wait-on dependency for this use case. Though it should be moved to a dev dependency since it's only used in the test setup.

[JacksonMeade]

Fixed