feat: close the last four domain events, and the panel paths they describe

Every one of the fourteen named events now has an emit point. The four that
were missing all sat on paths owned by earlier tasks:

- AppointmentCompleted fires from both status-change routes, after the row is
  saved. A rejected transition or a version conflict leaves no event; otherwise
  the completed count runs ahead of the appointments themselves.
- AppointmentRescheduled is a third event, not a replacement. A rebook is a
  confirm plus a cancel, and a consumer that only hears the cancel messages a
  patient who still has an appointment.
- ResourceBlocked / ResourceReleased are a pair. Capacity coming back has to be
  as audible as capacity going away, or the resource reads as permanently taken.

Publishing is now on the scheduler rather than an unregistered command: the
logic moved out of PublishDomainEventsCommand into OutboxPublisher so the
recurring message and the manual command share it, and the existing
worker-scheduler container consumes it. The scheduler message carries no data
on purpose — what to publish is read from the table, so an event recorded
between two ticks is not skipped. DomainEventMessage routes to async, since a
slow consumer was otherwise slowing the drain itself and its failure marked a
row failed that had in fact been delivered.

Panel work that these paths made reachable:

- Cancelling from the appointment page now goes through the policy-aware
  endpoint and shows the penalty preview before the confirm, so the operator
  does not discover the patient's penalty after the fact. The cancellation
  service writes the timeline entry itself and accepts a reason, which that
  path previously dropped on the floor.
- Rescheduling reuses the booking page under ?rebook=<uuid> — the search and
  hold steps are identical and only the final step differs. The doctor picker
  is hidden there: a reschedule is not an invitation to change doctors.
- A new GET /appointment/{uuid}/segments exposes the recorded plan. An empty
  list is not an error, it means the appointment is slot-based, and that is
  exactly what gates the resource-mode reschedule button.

AppointmentInvoiceCard no longer crashes the whole detail page when an older
invoice has no discount breakdown.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/api/appointment-booking.md

@@ -109,6 +109,42 @@ UNIQUE (resource_id, bucket_at, seat)
 جابه‌جایی: **اول** رزرو جدید، بعد آزادسازی قدیم. ترتیب عمدی است — اگر رزرو جدید شکست
 بخورد، نوبت قدیمی دست‌نخورده می‌ماند و بیمار بی‌نوبت نمی‌شود.
 
+```json
+{ "hold_uuid": "5e0e…" }
+```
+
+پاسخ: `appointment_uuid` · `released_intervals` (تعداد اشغال آزادشدهٔ زمان قبلی) ·
+`starts_at` (زمان تازه).
+
+سه رویداد دامنه ثبت می‌شود، نه یکی: `AppointmentBooked`، `AppointmentCancelled` و
+`AppointmentRescheduled`. سومی همان چیزی است که دو تای اول را به هم وصل می‌کند؛ بدون آن،
+مصرف‌کننده‌ای که فقط لغو را می‌شنود برای بیماری که هنوز نوبت دارد پیام لغو می‌فرستد.
+
+در پنل، همین مسیر با `/admin/resource-booking?rebook={uuid}` باز می‌شود: همان جستجو و
+رزرو موقت، فقط گام آخرش جابه‌جایی است.
+
+## `GET /api/v1/appointment/{uuid}/segments`
+
+بخش‌های **ثبت‌شدهٔ** نوبت — عکسِ لحظهٔ رزرو، نه الگوی امروزِ خدمت. تغییر بعدیِ الگو این
+فهرست را عوض نمی‌کند.
+
+```json
+{
+  "success": true,
+  "data": [
+    { "sequence": 1, "name": "بی‌حسی", "starts_at": 1811232000, "ends_at": 1811232300,
+      "duration_minutes": 5, "patient_present": true },
+    { "sequence": 2, "name": "انتظار", "starts_at": 1811232300, "ends_at": 1811234100,
+      "duration_minutes": 30, "patient_present": false }
+  ]
+}
+```
+
+**فهرست خالی خطا نیست** و یعنی نوبت اسلاتی است. پنل با همین تفاوت تصمیم می‌گیرد دکمهٔ
+جابه‌جایی منبع‌محور را نشان بدهد یا نه.
+
+**۴۰۴** روی نوبت محیط دیگر.
+
 ---
 
 ## اشغال: یک ردیف per (بخش × منبع)

docs/api/appointment.md

@@ -908,6 +908,8 @@ New optional fields on `Appointment` (all backward-compatible): `service_section
 New statuses: `following_up` (در حال پیگیری), `salon` (سالن). Transitions:
 `pending → confirmed|following_up|cancelled_*|expired` · `confirmed → completed|following_up|salon|cancelled_*|no_show` · `following_up → confirmed|salon|completed|cancelled_*|no_show` · `salon → completed|following_up|cancelled_*|no_show`
 
+**Domain event on completion.** Reaching `completed` — through either `PATCH /appointment/{uuid}/status` or the general `PATCH /appointment/{uuid}` — records an `AppointmentCompleted` domain event in the outbox (see [domain-events.md](../architecture/domain-events.md)). It is recorded **after** the row is saved, so a rejected transition or a version conflict leaves no event; otherwise the completed count would run ahead of the appointments themselves.
+
 ### PATCH `/api/v1/appointment/{uuid}`
 General update (ویرایش / جا به جایی / انتقال به رزرو / جایگزینی). All body fields optional; only present keys change. **Permission:** `appointments.update_status` per the [single-appointment access model](#single-appointment-access-model) — the appointment's owning doctor, admin, the clinic owner / member doctor / assigned secretary of `appointment.clinic`. The patient is **not** allowed here (view + cancel only).
 

docs/api/cancellation.md

@@ -98,10 +98,15 @@
 ## POST `/api/v1/appointment/{uuid}/cancel`
 
 ```json
-{ "by": "doctor" }
+{ "by": "doctor", "reason": "بیمار تماس گرفت" }
 ```
 
-`by` اختیاری است؛ نبودنش یعنی لغو از سمت بیمار.
+`by` اختیاری است؛ نبودنش یعنی لغو از سمت بیمار. `reason` هم اختیاری است و روی تایم‌لاین
+نوبت (`AppointmentEvent`) می‌نشیند — همان چیزی که اپراتور در صفحهٔ نوبت می‌بیند. بدون آن،
+لغو از مسیر سیاست هیچ ردی در تاریخچهٔ نوبت نمی‌گذاشت.
+
+پنل این اندپوینت را از دکمهٔ «لغو نوبت» صدا می‌زند و **پیش از تأیید** نتیجهٔ
+`cancellation-preview` را نشان می‌دهد؛ عددی که اپراتور می‌بیند همان است که کسر می‌شود.
 
 ### Response `200`
 ```json

docs/api/resource.md

@@ -407,3 +407,7 @@ npx vitest run assets/admin/pages/ResourcesPage.test.tsx
 
 اشغالی که به نوبت یا رزرو موقت وصل است از این مسیر حذف **نمی‌شود** (`422`) — وگرنه
 نوبت بیمار بی‌صدا منبعش را از دست می‌داد.
+
+هر دو عمل رویداد دامنه ثبت می‌کنند: `ResourceBlocked` و `ResourceReleased`. ظرفیتی که
+برمی‌گردد باید همان‌قدر شنیده شود که ظرفیتی که می‌رود؛ مصرف‌کننده‌ای که فقط اولی را
+بشنود، منبع را برای همیشه اشغال می‌بیند.

docs/architecture/domain-events.md

@@ -28,13 +28,30 @@
 | انتشار پیش از commit، بعد rollback | پیامک رفته، نوبتی وجود ندارد |
 | commit موفق، انتشار شکست خورد (Redis down) | نوبت هست، هیچ‌کس مطلع نشد |
 
-با outbox ردیف رویداد **در همان تراکنش** ثبت می‌شود و یک worker بعداً منتشرش می‌کند:
+با outbox ردیف رویداد **در همان تراکنش** ثبت می‌شود و بعداً منتشر می‌شود. حداکثر **تأخیر**
+داریم، هرگز گم‌شدن.
 
-```bash
-ddev exec php bin/console app:events:publish --limit=100
-```
+### چه چیزی آن را در تولید اجرا می‌کند
 
-حداکثر **تأخیر** داریم، هرگز گم‌شدن.
+انتشار روی زمان‌بند نشسته است، نه cron جدا: `PublishDomainEventsMessage` هر دقیقه در
+`src/Schedule.php` صادر می‌شود و `worker-scheduler` همان کانتینر همیشگی مصرفش می‌کند.
+سرویس تازه‌ای لازم نیست.
+
+| لایه | چه می‌کند |
+|---|---|
+| `OutboxPublisher::publish()` | منطق واقعی؛ ردیف‌های منتشرنشده را از جدول می‌خواند |
+| `PublishDomainEventsHandler` | هر تیک زمان‌بند صدایش می‌زند |
+| `app:events:publish --limit=100` | اجرای دستی، برای وقتی که صف عقب افتاده |
+
+پیامِ زمان‌بند عمداً **بی‌داده** است: «چه چیزی منتشر شود» از جدول خوانده می‌شود نه از پیام،
+وگرنه رویدادی که بین دو تیک ثبت شده جا می‌ماند. و چون `Schedule` روی `stateful` است، تیکِ
+ازدست‌رفته بعد از ری‌استارت جبران می‌شود — یک اجرا کافی است تا همهٔ عقب‌ماندگی برود.
+
+`DomainEventMessage` به `async` می‌رود، نه `sync`: یک مصرف‌کنندهٔ کند وگرنه خودِ تخلیهٔ صندوق
+را کند می‌کرد، و شکستش ردیفی را «ناموفق» علامت می‌زد که در واقع تحویل شده بود.
+
+پاکسازی (`app:events:prune`) روی زمان‌بند **نیست** و باید cron جدا باشد؛ حذف داده تصمیمی است
+که باید صریح و با پنجرهٔ نگه‌داریِ انتخاب‌شده اجرا شود، نه اثر جانبیِ یک worker همیشه‌روشن.
 
 `DomainEventPublisher::record()` عمداً flush نمی‌کند — همان چیزی که تضمین می‌کند رویداد
 با تراکنشِ برگشته از بین برود. جایی که فراخوان تراکنش باز ندارد، `recordAndFlush()` هست.
@@ -90,10 +107,21 @@ CreditConsumed           CreditRefunded
 | `CourseSessionCompleted` · `CourseCompleted` | `CourseSessionLinker::complete()` |
 | `PackagePurchased` | `PackageSalesService::sell()` |
 | `CreditConsumed` · `CreditRefunded` | `CreditLedgerService` |
+| `AppointmentRescheduled` | `BookingController::rebook()` |
+| `AppointmentCompleted` | `AppointmentController` — هر دو مسیر تغییر وضعیت |
+| `ResourceBlocked` · `ResourceReleased` | `ResourceBlockController` |
 
-`AppointmentRescheduled`، `AppointmentCompleted`، `ResourceBlocked` و `ResourceReleased`
-هنوز نقطهٔ ثبت ندارند: مسیرهایشان (جابه‌جایی نوبت، تکمیل دستی، بلوک منبع) از تسک‌های
-قبلی‌اند و دست‌زدن به آن‌ها بیرون از دامنهٔ این تسک بود.
+هر چهارده رویداد نقطهٔ ثبت دارند.
+
+دو نکته که موقع خواندن این جدول به‌درد می‌خورند:
+
+- **`AppointmentRescheduled` سومین رویداد است، نه جایگزین.** جابه‌جایی از درون یک `confirm`
+  و یک `cancel` است و هر کدام رویداد خودشان را می‌گذارند. مصرف‌کننده‌ای که فقط
+  `AppointmentCancelled` را بشنود، برای بیماری که هنوز نوبت دارد پیام لغو می‌فرستد؛ این
+  رویداد همان چیزی است که آن دو را به هم وصل می‌کند.
+- **`AppointmentCompleted` بعد از ذخیرهٔ موفق ثبت می‌شود، نه هنگام درخواست.** انتقالی که
+  `canTransitionTo` رد می‌کند یا `saveWithLock` روی تداخل نسخه می‌شکند، هیچ رویدادی
+  نمی‌گذارد — وگرنه شمارِ «انجام‌شده» از خودِ نوبت‌ها جلو می‌زند.
 
 ---
 

docs/deploy/coolify.md

@@ -14,8 +14,8 @@
 | سرویس | نقش | نکته |
 |-------|-----|------|
 | `app` | وب (PHP-FPM + Nginx) | دامنه به این سرویس اختصاص می‌یابد (پورت ۸۰). `RUN_INIT=1` → migration و تولید کلید JWT |
-| `worker-async` | مصرف صف `async` (ارسال SMS) | `RUN_INIT=0` |
-| `worker-scheduler` | مصرف `scheduler_default` (انقضای نوبت‌های پرداخت‌نشده، هر دقیقه) | `RUN_INIT=0` |
+| `worker-async` | مصرف صف `async` (ارسال SMS، مصرف‌کنندهٔ رویدادهای دامنه) | `RUN_INIT=0` |
+| `worker-scheduler` | مصرف `scheduler_default` (انقضای نوبت‌ها، انتشار صندوق خروجی رویدادها، هر دقیقه) | `RUN_INIT=0` |
 | `mariadb` | دیتابیس MariaDB 11.8 | healthcheck دارد؛ سرویس‌های اپ منتظر سالم‌شدن آن می‌مانند |
 | `redis` | Messenger transport + کش/OTP | با appendonly persist می‌شود |