Fix multiple critical bugs in onboarding training step

This commit addresses all identified bugs and issues in the training code path:

## Critical Fixes:
- Add get_start_time() method to TrainingLogRepository and fix non-existent method call
- Remove duplicate training.started event from API endpoint (trainer publishes the accurate one)
- Add missing progress events for 80-100% range (85%, 92%, 94%) to eliminate progress "dead zone"

## High Priority Fixes:
- Fix division by zero risk in time estimation with double-check and max() safety
- Remove unreachable exception handler in training_operations.py
- Simplify WebSocket token refresh logic to only reconnect on actual user session changes

## Medium Priority Fixes:
- Fix auto-start training effect with useRef to prevent duplicate starts
- Add HTTP polling debounce delay (5s) to prevent race conditions with WebSocket
- Extract all magic numbers to centralized constants files:
  - Backend: services/training/app/core/training_constants.py
  - Frontend: frontend/src/constants/training.ts
- Standardize error logging with exc_info=True on critical errors

## Code Quality Improvements:
- All progress percentages now use named constants
- All timeouts and intervals now use named constants
- Improved code maintainability and readability
- Better separation of concerns

## Files Changed:
- Backend: training_service.py, trainer.py, training_events.py, progress_tracker.py
- Backend: training_operations.py, training_log_repository.py, training_constants.py (new)
- Frontend: training.ts (hooks), MLTrainingStep.tsx, training.ts (constants, new)

All training progress events now properly flow from 0% to 100% with no gaps.

services/training/app/services/progress_tracker.py

@@ -10,6 +10,11 @@ from datetime import datetime, timezone
 
 from app.services.training_events import publish_product_training_completed
 from app.utils.time_estimation import calculate_estimated_completion_time
+from app.core.training_constants import (
+    PROGRESS_TRAINING_RANGE_START,
+    PROGRESS_TRAINING_RANGE_END,
+    PROGRESS_TRAINING_RANGE_WIDTH
+)
 
 logger = structlog.get_logger()
 
@@ -34,8 +39,8 @@ class ParallelProductProgressTracker:
         self.start_time = datetime.now(timezone.utc)
 
         # Calculate progress increment per product
-        # 60% of total progress (from 20% to 80%) divided by number of products
-        self.progress_per_product = 60 / total_products if total_products > 0 else 0
+        # Training range (from PROGRESS_TRAINING_RANGE_START to PROGRESS_TRAINING_RANGE_END) divided by number of products
+        self.progress_per_product = PROGRESS_TRAINING_RANGE_WIDTH / total_products if total_products > 0 else 0
 
         logger.info("ParallelProductProgressTracker initialized",
                    job_id=job_id,
@@ -80,9 +85,9 @@ class ParallelProductProgressTracker:
             estimated_completion_time=estimated_completion_time
         )
 
-        # Calculate overall progress (20% base + progress from completed products)
+        # Calculate overall progress (PROGRESS_TRAINING_RANGE_START% base + progress from completed products)
         # This calculation is done on the frontend/consumer side based on the event data
-        overall_progress = 20 + int((current_progress / self.total_products) * 60)
+        overall_progress = PROGRESS_TRAINING_RANGE_START + int((current_progress / self.total_products) * PROGRESS_TRAINING_RANGE_WIDTH)
 
         logger.info("Product training completed",
                    job_id=self.job_id,
@@ -99,5 +104,5 @@ class ParallelProductProgressTracker:
         return {
             "products_completed": self.products_completed,
             "total_products": self.total_products,
-            "progress_percentage": 20 + int((self.products_completed / self.total_products) * 60)
+            "progress_percentage": PROGRESS_TRAINING_RANGE_START + int((self.products_completed / self.total_products) * PROGRESS_TRAINING_RANGE_WIDTH)
         }