v1.4.0

Co nowego:
- Wsparcie Active Directory dla LDAP (obok LLDAP/OpenLDAP), przełącznik typu
  katalogu w Admin > Integracje.
- Wyszukiwarka klientów dla operatora (Operator > Klienci).
- Stronicowanie kolejki operatora (50/stronę) i dashboardu klienta (20/stronę).
- Globalna wyszukiwarka zgłoszeń (Ctrl+K/Cmd+K) z operatorami w stylu Gmaila
  (od:, temat:, treść:, numer:), plus przycisk "Szukaj" w panelu bocznym.
- Ostatnio przeglądane zgłoszenia w panelu bocznym operatora.
- Przeprojektowany pasek nawigacji: suwak Klient/Operator/Administrator
  zamiast rozwijanego menu, bogatsze menu profilu (nazwa/e-mail/role),
  dynamiczne tytuły kart przeglądarki na każdej podstronie.
- Narzędzie do jednorazowego importu historii zgłoszeń z Heska 3.x
  (scripts/hesk-import/).
- Poprawka: paginacja pokazywała surowe klucze tłumaczeń zamiast tekstu
  (brakujący lang/pl/pagination.php).

Zaktualizowana dokumentacja: README, CLAUDE.md, install.md, ARCHITECTURE.md,
CHANGELOG.md, wiki/*.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -21,7 +21,12 @@ roles). Treat the running database as production, not a sandbox:
 ## Container operations: use `sudo`, never build the image locally
 
 All Docker commands against this stack need `sudo` (e.g.
-`sudo docker compose exec servicedesk ...`, `sudo docker exec servicedesk-servicedesk-1 ...`).
+`sudo docker compose exec app ...`, `sudo docker exec servicedesk-app-1 ...`).
+
+The stack is four services sharing the one `servicedesk` image — `app` (Apache,
+what actually serves HTTP), `reverb` (websocket server, `php artisan
+reverb:start`), `cron` (scheduler loop, `php artisan schedule:work` — see
+below), and `mariadb`. Only `app` and `reverb` are reachable from Traefik.
 
 **Never run `docker build`, `docker compose build`, or `--build`.** The
 `servicedesk` image is built by CI (`.gitea/workflows/build.yml`, triggered on
@@ -29,7 +34,7 @@ All Docker commands against this stack need `sudo` (e.g.
 `compose.yaml` only ever `pull`s a tag (`sudo docker compose pull && sudo docker
 compose up -d`, see [install.md](install.md) 1.3/1.3a) — building locally would
 just diverge from what CI produces. The app container
-(`servicedesk-servicedesk-1`) mounts `./src` from the host over NFS
+(`servicedesk-app-1`) mounts `./src` from the host over NFS
 (`/mnt/rabbit-containers` → NFS export), so plain file edits already take effect
 with no rebuild or restart:
 
@@ -56,33 +61,32 @@ with no rebuild or restart:
   surfaces in production as a 500 with `touch(): Utime failed: Operation not
   permitted`. If you ran `php artisan test`/`tinker`/any artisan command via
   `docker exec` in a session where you also edited Blade files afterward,
-  finish with `sudo docker exec servicedesk-servicedesk-1 php artisan
+  finish with `sudo docker exec servicedesk-app-1 php artisan
   view:clear` to flush any root-owned compiled views before ending the
   session — don't wait for a report of a broken page to catch it.
 
-## Scheduled commands need a host crontab entry
+## Scheduled commands run in the dedicated `cron` container
 
 The Docker image ships no cron/supervisor of its own (see [install.md](install.md)),
 so `tickets:check-sla-breaches`, `automation:run-rules`, `emails:fetch-imap`,
 and `ai:run-ticket-automation` (all registered in `routes/console.php` via
-`Schedule::command(...)`) only ever run if something outside the container
-calls `php artisan schedule:run` on a timer. **As of 2026-07-23 this is
-configured** — root's crontab on the host runs, every minute:
+`Schedule::command(...)`) only ever run if something calls `php artisan
+schedule:run` on a timer. **As of 2026-08-04 this is the `cron` service** in
+`compose.yaml` — same `servicedesk` image, running `php artisan schedule:work`
+(Laravel's own foreground scheduler loop, ticks every minute internally, no
+external trigger needed). Before this it was a root crontab entry on the host
+calling `docker compose exec -T servicedesk schedule:run`; that entry has been
+removed from `sudo crontab -l -u root` now that the container replaces it —
+don't re-add it, the two would double-run every scheduled command.
 
-```cron
-* * * * * cd /mnt/rabbit-containers/servicedesk && docker compose exec -T servicedesk php artisan schedule:run >> /dev/null 2>&1
-```
-
-(`sudo crontab -l -u root` to inspect/edit — it previously did not exist at all,
-which meant none of the four scheduled commands above had ever run
-automatically; ask before changing this again, since removing it silently
-breaks SLA checks, automation rules, IMAP fetching and AI ticket automation,
-and confusingly not the IMAP feature alone if you're only debugging that one.)
-IMAP-specific activity (connect attempts, per-message accept/reject decisions,
-created/replied ticket ids) is logged separately from the app's normal
-`LOG_LEVEL` to `storage/logs/imap-*.log` (see the `imap` channel in
-`config/logging.php`) — check there first when a mailbox isn't behaving as
-expected, before assuming the scheduler itself isn't firing.
+If the `cron` container isn't running (`sudo docker compose ps cron`), none of
+the four scheduled commands fire — same failure mode as the old missing-crontab
+case, just check the container instead of the crontab. IMAP-specific activity
+(connect attempts, per-message accept/reject decisions, created/replied ticket
+ids) is logged separately from the app's normal `LOG_LEVEL` to
+`storage/logs/imap-*.log` (see the `imap` channel in `config/logging.php`) —
+check there first when a mailbox isn't behaving as expected, before assuming
+the scheduler itself isn't firing.
 
 All four commands' intervals are admin-configurable (Admin > Konfiguracja —
 `schedule_sla_check_minutes`/`schedule_automation_rules_minutes`/