fix(appointments): file the case file on every confirmation path

Confirming an appointment was supposed to create the patient's record and its
session, and PatientService already knew how. Only two of the five paths that
confirm an appointment ever called it, and the one that mattered most did not:
a booking paid for online was confirmed inside the payment callback, which
never ran the side-effects. Every Nobat724 booking therefore went unfiled — 7
confirmed appointments in dev had no session at all.

The side-effects now run through AppointmentConfirmationService, which every
path calls: the payment callback, both PATCH endpoints, and panel/admin
bookings. Creating the record can no longer roll back a confirmation or a
payment; a failure is logged and can be repaired with the new
app:appointment:backfill-sessions command.

Two related defects fixed along the way:

- A doctor working at a clinic got two records for one appointment, one under
  the doctor and one under the clinic, so a single visit's revenue was counted
  twice. The booking context now decides, and it decides once.
- That context was inferred from address_id, falling back to "the doctor's only
  clinic" — a guess that files an appointment under the wrong practice now that
  schedules are per-context. It is stored as appointments.clinic_id instead.

Panel and admin bookings were left pending forever: nothing confirmed them and
no payment was expected. They are created confirmed.

Repeat confirmations no longer duplicate the session; an archived one still
counts as filed, so archiving a mistaken visit does not resurrect it.

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

docs/api/appointment.md

@@ -712,6 +712,24 @@ On `POST /api/v1/appointment`, any `service_item_uuids` must belong to the same
 `422 ERR_VALIDATION_001` («سرویس انتخاب‌شده به این محل نوبت‌دهی تعلق ندارد»). The appointment's
 `address_id` is resolved from that context's schedule.
 
+**The context is stored on the row.** All three booking paths persist it as
+`appointments.clinic_id` (`NULL` = personal practice). Downstream consumers — above all the
+automatic case-file creation documented in [patient.md](patient.md#auto-creation-on-appointment-confirm) —
+read that column instead of inferring the clinic from `address_id`. The old inference had a
+fallback of "the doctor's only clinic", which silently filed appointments under the wrong practice
+once per-context schedules existed.
+
+### وضعیت اولیهٔ نوبت
+
+| مسیر | وضعیت هنگام ثبت |
+|---|---|
+| `POST /api/v1/appointment` (سایت عمومی) | `pending` با TTL پرداخت (`Appointment::PAYMENT_TTL` = ۱۵ دقیقه)؛ با پرداخت موفق `confirmed` می‌شود |
+| `POST /api/v1/my/appointment` (پنل) | مستقیم `confirmed` |
+| admin booking | مستقیم `confirmed` |
+
+نوبتی که خودِ کلینیک/پزشک ثبت می‌کند پرداخت آنلاین ندارد و منتظر چیزی نیست؛ `pending` ماندنش
+یعنی نه در تقویم درست شمرده می‌شود و نه پرونده می‌سازد.
+
 > **Silent-failure warning:** before this change the location was inferred from the doctor's single
 > schedule. A client that does not send `clinic_uuid` will now book into the personal practice —
 > which is correct, but is a behaviour change for any doctor who also works in a clinic. Update