Document the resource-first model and retire the deleted tasks' checklists

docs/architecture/resource-first-model.md describes the shape: the three
entities, why an option is a ServiceItem rather than a fourth table, the
four-level resolution chain, the two conditions on the eligibility filter and
what each of them prevented, and why containment is a graph beside the display
tree rather than the tree itself.

docs/api/resource.md gains both offering endpoints with the response captured
from a real call, including a row where the price comes from the branch and one
where it comes from the resource — the two cases the *_source fields exist for.
docs/api/appointment.md documents resource_uuid, the doctor inference, and the
nullable resource/service_option in the response.

The checklists for tasks 9 to 14 keep their rows but open with a banner saying
the task was removed, when, by whose decision, and which commit to revert. They
are history now; deleting them would erase the record of work that shipped and
was then withdrawn.

Verified end to end: 1304 tests, slot-mode-frozen green, phpstan at 14, tsc
clean, 648 panel tests, and app:seed-scenarios --reset builds all three
environments.

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

TEST_USERS.md

@@ -95,17 +95,18 @@ POST /api/v1/auth/switch-context  {"db_uuid": "<clinic_uuid>"}
 | ۰۵ برنامهٔ چندبخشی | سرویس اصلی هر محیط سه بخش دارد: بی‌حسی ۵د (اتاق انحصاری) → انتظار ۳۰د (اتاق **passive**) → لیزر ۲۰د (اتاق + دستگاه) | `GET /api/v1/service-item/{uuid}/segments` |
 | ۰۶ موتور دسترس‌پذیری | همان برنامه با منابع واقعی جستجو می‌شود | `POST /api/v1/appointment-availability` |
 | ۰۷ نگه‌داشتن و ثبت | **۲ نوبت در هر محیط از مسیر واقعی** hold → confirm، با بخش و اشغال منبع | `GET /api/v1/appointment/{uuid}/segments` |
+| **منبع↔سرویس** | رابطهٔ چند‌به‌چند با مدت و قیمت اختصاصی: دو دستگاه یک سرویس را با اعداد متفاوت می‌دهند | `GET /api/v1/resource/{uuid}/services` |
+| **دستهٔ مشترک** | دسته روی سرویس و منبع؛ یال «شامل بودن» بین دسته‌ها | مودال «سرویس‌ها» در صفحهٔ منابع |
 | ۰۸ عکس قیمت | لیست قیمت فعال + `PriceSnapshot` روی نوبت‌های واقعی با بیعانه | `GET /api/v1/price-lists` |
-| ۰۹ موتور سیاست | **۶ سیاست، یکی از هر دسته** (انتخاب، صلاحیت، منبع، زمان، فاصله، قیمت) | `GET /api/v1/policies` |
-| ۱۱ پکیج و دفتر اعتبار | پکیج ۶ جلسه‌ای + ۲ پکیج خریداری‌شده + ردیف مصرف در دفتر | `GET /api/v1/packages` |
-| ۱۲ دورهٔ درمان | پروتکل ۶ جلسه‌ای با پارامتر انرژی هر جلسه + دورهٔ فعال با ۶ جلسه | `GET /api/v1/treatment-course/{uuid}` |
-| ۱۳ لغو و لیست انتظار | سیاست عمومی + سیاست سخت‌گیرانه روی یک سرویس، رکورد عدم حضور، ۲ نفر در لیست انتظار | `GET /api/v1/waitlist` · `/cancellation-policy` |
-| ۱۴ رویداد و بهره‌وری | `HoldCreated` و `AppointmentBooked` در outbox + دقیقهٔ اشغال واقعی هر منبع | `GET /api/v1/reports/resource-utilization?branch_uuid=…` |
+
+> **تسک‌های ۹ تا ۱۴ (سیاست، پکیج، دوره، لغو/انتظار، رویداد و گزارش) به تصمیم مالک محصول
+> از محصول حذف شده‌اند.** مدل فعلی فقط منبع، سرویس و گزینه است —
+> [`docs/architecture/resource-first-model.md`](docs/architecture/resource-first-model.md).
 
 نوبت‌های موتور جدید **از `new Appointment(...)` ساخته نمی‌شوند**؛ از
 `AppointmentPlanBuilder` → `AvailabilityEngine` → `HoldService` → `BookingService` رد
-می‌شوند. برای همین اشغال منبع و رویداد دامنه واقعی‌اند: گزارش بهره‌وری عدد نشان می‌دهد و
-تقویم دستگاه واقعاً پر است.
+می‌شوند. برای همین اشغال منبع واقعی است و تقویم دستگاه واقعاً پر است — نه ردیف‌هایی که
+با INSERT ساخته شده‌اند و هیچ‌وقت از موتور رد نشده‌اند.
 
 ## چه چیزی با این داده قابل تست است