**Issue**: Backtesting service crashing with "transport error"
**Root Cause #3**: blocking_read() called in async context causing panic
## Fixes Applied
### Agent 413: Async/Blocking Conflict Resolution
- **File**: services/backtesting_service/src/service.rs
- **Problem**: `blocking_read()` at line 237 panicked within Tokio runtime
- **Error**: "Cannot block the current thread from within a runtime"
- **Why Hard to Debug**: Panic manifested as gRPC transport error, not panic message
- **Fix**:
- Line 215: Made validate_backtest_request() async
- Line 237: Changed `blocking_read()` → `read().await`
- Line 406: Added `.await` to function call
- **Impact**: Service stability restored, no more transport errors
### Debug Enhancement
- **File**: services/api_gateway/src/auth/interceptor.rs:362
- **Added**: Full token logging for JWT debugging
- **Purpose**: Debugging aid for Wave 149 investigation
## Technical Discovery
**Key Insight**: Async/blocking conflicts cause service crashes that appear as
transport errors at the client level. Always check service logs for panic
backtraces when debugging transport failures.
## Test Results
- Before: 29/49 (59.2%)
- After Phase 3-4: 29/49 (59.2%)
- Service Status: Stable (no more panics)
## Files Modified
- services/backtesting_service/src/service.rs (+3 lines async conversion)
- services/api_gateway/src/auth/interceptor.rs (+1 line debug logging)
Co-authored-by: Wave 149 Agent 413 (Service Panic Fix)
52c3862db9