refactor: address code review findings across all projects

Apply comprehensive fixes from code reviews including:
- Extract shared utilities (SqlFormatHelper, CellValueConverter, DbDestinationBase)
- Add interface abstractions (IAuthenticationService, IDatabaseMigrator, IMisQueryBuilder)
- Implement SecureStore for encrypted secrets storage
- Fix error handling with proper HTTP status codes and logging
- Optimize double enumeration in DevEtlRegistry
- Add DataSync.Dev README for developer onboarding
- Extract filter panel base classes to reduce duplication
- Update code review docs to mark all issues as fixed

CodeReviews/Api/review.md

@@ -0,0 +1,186 @@
+# Code Review: JdeScoping.Api
+
+**Project Path:** `NEW/src/JdeScoping.Api`
+**Layer:** Presentation
+**Purpose:** ASP.NET Core Web API, controllers, SignalR hubs
+
+---
+
+## Executive Summary
+
+The JdeScoping.Api project is a well-structured ASP.NET Core Web API presentation layer. The codebase demonstrates good adherence to modern .NET practices, proper use of dependency injection, and clean architecture principles.
+
+**Overall Assessment: Good** with areas for improvement
+
+| Category | Rating | Notes |
+|----------|--------|-------|
+| SOLID Principles | Good | Minor SRP violations in some controllers |
+| Clean Architecture | Excellent | Proper layer separation |
+| Code Organization | Good | Well-organized partial classes |
+| Error Handling | Needs Improvement | Inconsistent patterns |
+| Testability | Good | DI used throughout |
+| Code Duplication | Needs Improvement | DRY violations in FileIOController |
+| Async Patterns | Good | Mostly correct usage |
+| Null Safety | Good | Nullable enabled, some gaps |
+| Documentation | Excellent | Comprehensive XML comments |
+
+---
+
+## 1. SOLID Principles
+
+### Single Responsibility Principle (SRP)
+
+**✅ FIXED: PipelineController mapping logic extracted**
+
+The `PipelineController` mapping logic has been extracted to a dedicated `IPipelineMapper` interface and `PipelineMapper` implementation in the `Mapping/` folder. The controller now delegates to the injected mapper.
+
+**Issue: RefreshStatusController performs data aggregation**
+
+The controller performs complex LINQ aggregation that belongs in a service layer.
+
+**Recommendation:** Move aggregation logic to a service class.
+
+### Dependency Inversion Principle (DIP)
+
+**Positive:** All controllers properly depend on abstractions via constructor injection.
+
+### Open/Closed Principle (OCP)
+
+**Issue:** `StatusHub` uses static mutable state which is problematic for testability.
+
+**Recommendation:** Replace static state with `IMemoryCache` or a dedicated caching service.
+
+---
+
+## 2. Clean Architecture
+
+### Excellent Practices
+
+1. **Proper dependency direction:** Api project depends on Core (interfaces) and Infrastructure
+2. **Centralized route definitions:** Routes defined in `ApiRoutes` class in Core
+3. **Base controller abstraction:** `ApiControllerBase` provides common functionality
+
+### Minor Violations
+
+**✅ FIXED:** `PipelineController` now inherits from `ApiControllerBase`, consistent with other controllers.
+
+---
+
+## 3. Code Organization
+
+### Positive Observations
+
+1. **Good use of partial classes** for FileIOController
+2. **Logical folder structure:** Controllers, Extensions, Hubs, Models, Options, Services
+
+---
+
+## 4. Error Handling
+
+### Critical Issues
+
+**Issue: Inconsistent error response patterns in FileIOController**
+
+Returning `200 OK` for error conditions violates HTTP semantics:
+
+```csharp
+if (file is null)
+{
+    return Ok(new FileUploadResult<WorkOrderViewModel>
+    {
+        WasSuccessful = false,
+        ErrorMessage = "No file uploaded"
+    });
+}
+```
+
+**Recommendation:** Return `BadRequest()` for validation failures.
+
+### Positive Error Handling
+
+The `SearchNotificationService` correctly implements best-effort notification pattern with logging.
+
+---
+
+## 5. Testability
+
+### Positive Aspects
+
+1. Constructor injection throughout
+2. Interface-based dependencies
+3. Proper service registration
+
+### Issues Affecting Testability
+
+1. Static state in `StatusHub`
+2. Direct `DateTime.UtcNow` usage - inject `TimeProvider` for testability
+
+---
+
+## 6. Code Duplication (DRY Violations)
+
+### Critical: Repetitive upload handling pattern
+
+The upload methods follow identical patterns repeated 4 times in FileIOController.
+
+**Recommendation:** Extract to a generic handler method.
+
+---
+
+## 7. Async Patterns
+
+### Positive Observations
+
+1. Proper async/await usage
+2. CancellationToken propagation
+3. Correct use of `await using` for streams
+
+### Issues
+
+**Issue:** `PartOperations` upload method is synchronous unlike other upload methods.
+
+---
+
+## 8. Null Safety
+
+### Positive: Nullable reference types enabled
+
+### Issues
+
+~~**Issue:** Null-forgiving operator usage without validation in SearchController.~~ ✅ FIXED
+
+~~**Recommendation:** Add explicit null validation:~~
+```csharp
+if (CurrentUserName is null)
+{
+    return Unauthorized();
+}
+```
+**Status:** Explicit null checks have been added to all methods in `SearchController` that use `CurrentUserName`. Methods now return `Unauthorized()` if the claim is missing.
+
+---
+
+## 9. Documentation
+
+### Excellent: Comprehensive XML documentation
+
+All public APIs have XML documentation with `ProducesResponseType` attributes.
+
+---
+
+## Recommendations Summary
+
+### Critical Priority
+1. Fix error response status codes in FileIOController
+2. Remove static state from StatusHub
+3. ~~Extract mapping logic from PipelineController~~ ✅ FIXED - Extracted to `IPipelineMapper`/`PipelineMapper` in `Mapping/` folder
+
+### High Priority
+4. Extract aggregation logic from RefreshStatusController
+5. Reduce code duplication in FileIOController
+6. ~~Add null validation before using null-forgiving operators~~ ✅ FIXED
+
+### Medium Priority
+7. ~~Make PipelineController inherit from ApiControllerBase~~ ✅ FIXED
+8. Make PartOperations upload method async
+9. Replace direct DateTime.UtcNow usage with TimeProvider