fix(timer): respect Settings.single_active_timer at runtime

Timer starts always blocked a second running entry and never read the\nadmin-controlled Settings flag.\n\n- Add TimeTrackingService.can_start_timer() using Settings.get_settings()\n  and wire it into start_timer, web timer routes, kiosk start, and\n  legacy POST /api/timer/resume.\n- POST /api/v1/timer/start returns 409 with error_code\n  timer_already_running when single-active mode is on and a timer\n  is already running.\n- Deduplicate start_timer template handling in the service.\n\nTests: tests/test_single_active_timer_setting.py.\nDocs: REST_API (responses), GETTING_STARTED, REQUIREMENTS, Docker env\nnotes, TESTING_STRATEGY, env.example comment; CHANGELOG entry.

docs/api/REST_API.md

@@ -620,6 +620,13 @@ POST /api/v1/timer/start
 }
 ```
 
+**Responses:**
+- **`201 Created`** — Timer started; JSON includes `message` and `timer` (time entry fields).
+- **`409 Conflict`** — **Allow only one active timer per user** is enabled in **System Settings** (`single_active_timer`) and the user already has a running timer. Response uses the standard error shape with `error_code` set to `timer_already_running`.
+- **`400 Bad Request`** — Validation or other errors (e.g. invalid project, inactive project).
+
+Enforcement uses the persisted **Settings** row, not the `SINGLE_ACTIVE_TIMER` env var alone (the env var seeds the setting on first install).
+
 #### Stop Timer
 ```
 POST /api/v1/timer/stop