feat: Enhance frontend loading experience and service status handling

### Summary of Changes
- Removed proxy configuration in `rsbuild.config.js` as the API Gateway is not running.
- Added smooth transitions and gentle loading overlays in CSS for improved user experience during data loading.
- Updated `Dashboard` component to conditionally display loading spinner and gentle loading overlay based on data fetching state.
- Enhanced `useOfflineAwareServiceStatus` and `useOfflineAwareSystemData` hooks to manage loading states and service status more effectively.
- Increased refresh intervals for service status and system data to reduce API call frequency.

### Expected Results
- Improved user experience with smoother loading transitions and better feedback during data refreshes.
- Enhanced handling of service status checks, providing clearer information when services are unavailable.
- Streamlined code for managing loading states, making it easier to maintain and extend in the future.

services/service-adapters/LOGGING.md

@@ -0,0 +1,148 @@
+# Unified Logging Configuration
+
+This document describes the unified logging setup and usage in the LabFusion Service Adapters.
+
+## Overview
+
+The service adapters use Python's built-in `logging` module with a centralized configuration system that provides **unified logging for both application logs and incoming request logs**. All logs use the same format, handler, and configuration for consistency and easier monitoring.
+
+## Logging Levels
+
+- **DEBUG**: Detailed information for debugging (status checker operations)
+- **INFO**: General information about application flow
+- **WARNING**: Warning messages for non-critical issues
+- **ERROR**: Error messages for failed operations
+- **CRITICAL**: Critical errors that may cause application failure
+
+## Configuration
+
+Logging is configured in `services/logging_config.py` with unified settings:
+
+- **Root Level**: INFO
+- **Status Checker**: DEBUG (detailed health check logging)
+- **Routes**: INFO (API endpoint logging)
+- **Request Logging**: INFO (unified with application logs)
+- **HTTP Client**: WARNING (reduced verbosity)
+- **Unified Handler**: Single handler for all log types
+
+## Log Format
+
+**Unified Format** (same for application and request logs):
+```
+2024-01-15 10:30:45,123 - services.status_checker - INFO - status_checker.py:140 - Starting health check for 4 services
+2024-01-15 10:30:45,124 - uvicorn.access - INFO - logging_middleware.py:45 - Request started: GET /services from 192.168.1.100
+2024-01-15 10:30:45,125 - routes.general - INFO - general.py:78 - Service status endpoint called - checking all services
+2024-01-15 10:30:45,126 - uvicorn.access - INFO - logging_middleware.py:55 - Request completed: GET /services -> 200 in 0.123s
+```
+
+Format includes:
+- Timestamp
+- Logger name (unified across all log types)
+- Log level
+- Filename and line number
+- Message
+
+## Usage Examples
+
+### Basic Logging
+```python
+import logging
+from services.logging_config import get_logger
+
+logger = get_logger(__name__)
+
+logger.debug("Debug information")
+logger.info("General information")
+logger.warning("Warning message")
+logger.error("Error occurred")
+```
+
+### Request Logging
+```python
+from services.logging_config import get_request_logger
+
+request_logger = get_request_logger()
+request_logger.info("Custom request log message")
+```
+
+### Application Logging
+```python
+from services.logging_config import get_application_logger
+
+app_logger = get_application_logger()
+app_logger.info("Application-level log message")
+```
+
+### Service Status Logging
+The status checker automatically logs:
+- Health check start/completion
+- Individual service responses
+- Response times
+- Error conditions
+- Authentication status
+
+### API Endpoint Logging
+Routes log:
+- Endpoint calls
+- Request processing
+- Response generation
+
+### Request Middleware Logging
+The logging middleware automatically logs:
+- Request start (method, path, client IP, user agent)
+- Request completion (status code, processing time)
+- Request errors (exceptions, processing time)
+
+## Debug Endpoint
+
+A debug endpoint is available at `/debug/logging` to:
+- Test unified log levels across all logger types
+- View current configuration
+- Verify unified logging setup
+- Test request, application, and route loggers
+
+## Environment Variables
+
+You can control logging behavior with environment variables:
+
+```bash
+# Set log level (DEBUG, INFO, WARNING, ERROR, CRITICAL)
+export LOG_LEVEL=DEBUG
+
+# Disable timestamps
+export LOG_NO_TIMESTAMP=true
+```
+
+## Log Files
+
+Currently, logs are output to stdout. For production, consider:
+- File logging with rotation
+- Structured logging (JSON)
+- Log aggregation (ELK stack, Fluentd)
+- Log levels per environment
+
+## Troubleshooting
+
+### No Logs Appearing
+1. Check log level configuration
+2. Verify logger names match module names
+3. Ensure logging is initialized before use
+
+### Too Many Logs
+1. Increase log level to WARNING or ERROR
+2. Disable DEBUG logging for specific modules
+3. Use log filtering
+
+### Performance Impact
+1. Use appropriate log levels
+2. Avoid logging in tight loops
+3. Consider async logging for high-volume applications
+
+## Best Practices
+
+1. **Use appropriate levels**: DEBUG for development, INFO for production
+2. **Include context**: Service names, request IDs, user information
+3. **Structured messages**: Consistent format for parsing
+4. **Avoid sensitive data**: No passwords, tokens, or personal information
+5. **Performance**: Log asynchronously when possible
+6. **Monitoring**: Set up alerts for ERROR and CRITICAL levels