Add fail2ban log viewer and service health to Config page

Task 2: adds a new Log tab to the Configuration page.

Backend:
- New Pydantic models: Fail2BanLogResponse, ServiceStatusResponse
  (backend/app/models/config.py)
- New service methods in config_service.py:
    read_fail2ban_log() — queries socket for log target/level, validates the
    resolved path against a safe-prefix allowlist (/var/log) to prevent
    path traversal, then reads the tail of the file via the existing
    _read_tail_lines() helper; optional substring filter applied server-side.
    get_service_status() — delegates to health_service.probe() and appends
    log level/target from the socket.
- New endpoints in routers/config.py:
    GET /api/config/fail2ban-log?lines=200&filter=...
    GET /api/config/service-status
  Both require authentication; log endpoint returns 400 for non-file log
  targets or path-traversal attempts, 502 when fail2ban is unreachable.

Frontend:
- New LogTab.tsx component:
    Service Health panel (Running/Offline badge, version, jail count, bans,
    failures, log level/target, offline warning banner).
    Log viewer with color-coded lines (error=red, warning=yellow,
    debug=grey), toolbar (filter input + debounce, lines selector, manual
    refresh, auto-refresh with interval selector), truncation notice, and
    auto-scroll to bottom on data updates.
  fetchData uses Promise.allSettled so a log-read failure never hides the
  service-health panel.
- Types: Fail2BanLogResponse, ServiceStatusResponse (types/config.ts)
- API functions: fetchFail2BanLog, fetchServiceStatus (api/config.ts)
- Endpoint constants (api/endpoints.ts)
- ConfigPage.tsx: Log tab added after existing tabs

Tests:
- Backend service tests: TestReadFail2BanLog (6), TestGetServiceStatus (2)
- Backend router tests: TestGetFail2BanLog (8), TestGetServiceStatus (3)
- Frontend: LogTab.test.tsx (8 tests)

Docs:
- Features.md: Log section added under Configuration View
- Architekture.md: config.py router and config_service.py descriptions updated
- Tasks.md: Task 2 marked done

Docs/Features.md

@@ -220,6 +220,27 @@ A page to inspect and modify the fail2ban configuration without leaving the web
 - Countries with zero bans remain transparent (no fill).
 - Changes take effect immediately on the World Map view without requiring a page reload.
 
+### Log
+
+- A dedicated **Log** tab on the Configuration page shows fail2ban service health and a live log viewer in one place.
+- **Service Health panel** (always visible):
+  - Online/offline **badge** (Running / Offline).
+  - When online: version, active jail count, currently banned IPs, and currently failed attempts as stat cards.
+  - Log level and log target displayed as meta labels.
+  - Warning banner when fail2ban is offline, prompting the user to check the server and socket configuration.
+- **Log Viewer** (shown when fail2ban logs to a file):
+  - Displays the tail of the fail2ban log file in a scrollable monospace container.
+  - Log lines are **color-coded by severity**: errors and critical messages in red, warnings in yellow, debug lines in grey, and informational lines in the default color.
+  - Toolbar controls:
+    - **Filter** — substring input with 300 ms debounce; only lines containing the filter text are shown.
+    - **Lines** — selector for how many tail lines to fetch (100 / 200 / 500 / 1000).
+    - **Refresh** button for an on-demand reload.
+    - **Auto-refresh** toggle with interval selector (5 s / 10 s / 30 s) for live monitoring.
+  - Truncation notice when the total log file line count exceeds the requested tail limit.
+  - Container automatically scrolls to the bottom after each data update.
+- When fail2ban is configured to log to a non-file target (STDOUT, STDERR, SYSLOG, SYSTEMD-JOURNAL), an informational banner explains that file-based log viewing is unavailable.
+- The log file path is validated against a safe prefix allowlist on the backend to prevent path-traversal reads.
+
 ---
 
 ## 7. Ban History