Resolve Duplicate UserProgress Entity Conflict

Description:

There are two separate UserProgress entity classes in the backend that both map to a user_progress database table. TypeORM will behave unpredictably when two entities share the same table name - migrations may conflict, queries may use the wrong entity, and relation resolution will be unreliable.

Current Behavior:

1. Entity 1: located in progress/entities/progress.entity.ts:

• Uses @PrimaryGeneratedColumn() (numeric ID)
• Has full TypeORM relations to User, Puzzle, Category, and DailyQuest
• Includes dailyQuestId as an optional foreign key
• Has indexes on [userId, attemptedAt], [userId, puzzleId], [categoryId], [dailyQuestId]

2. Entity 2: also appears to be in the progress folder:

• Uses @PrimaryGeneratedColumn('uuid') (UUID)
• Has no relations - only raw column definitions
• Has a composite index on [userId, categoryId, attemptedAt]
• Uses @CreateDateColumn for attemptedAt instead of a manual timestamp column

Both are named UserProgress and both declare @Entity('user_progress').

Expected Behavior:

There should be exactly one UserProgress entity that is the single source of truth for the user_progress table. All services, controllers, and providers that reference UserProgress should import from one consistent location.

Requirements:

• Audit all files that import UserProgress and identify which entity they are using
• Determine which entity definition is more complete and consistent with the rest of the codebase - Entity 1 (with full relations) is likely the correct one given it connects to DailyQuest, Puzzle, Category, and User
• Delete or archive the redundant entity
• Ensure the surviving entity's schema is consistent with what is actually in the database (check existing migrations if any)
• Update all imports across the codebase to point to the single remaining entity
• Verify that ProgressService, ProgressController, DailyQuestService, and any other consumers all resolve correctly after the change
• Run the full TypeScript type check (tsc --noEmit) to confirm no broken imports remain

Acceptance Criteria:

• Only one UserProgress entity exists in the codebase
• It maps to the user_progress table without conflict
• All services and controllers that use UserProgress import from the same path
• No TypeORM warnings or errors appear on application startup
• npm --workspace backend exec -- tsc --noEmit -p tsconfig.json passes cleanly
• Existing progress-related API endpoints continue to function correctly