fix(secretary): settings menu structure, clinic timeline access, patient delete gate

Three reported secretary-access bugs.

1) Settings menu structure. Phase B flat-listed staff/discounts/sms/tags/
   appointment_settings/clinic_doctors in the secretary's main sidebar. Mirror
   the doctor/clinic layout instead: only inventory + services stay in the main
   «مدیریت» nav; the rest live under a single «تنظیمات» entry
   (→ /admin/account-settings). Made both settings navs permission-aware for
   secretaries: SETTINGS_MENU (menuForRole now takes `can`) and
   PurchaseSubscriptionSidebar filter by a per-item `perm`/`alwaysOpen` instead
   of role only, so a secretary sees exactly their permitted settings pages and
   owner-only items (subscription, secretary-management) stay hidden.

2) Clinic secretary appointment timeline. AppointmentsPage treated a
   clinic-scoped secretary as a single-doctor profile: the doctor list was
   fetched/shown only for isClinic/isAdmin, so no doctor tabs, timeline, or
   booking. Now a clinic-scoped secretary is multi-doctor: fetches the doctor
   list, shows tabs, auto-selects the first doctor. The list comes from a new
   authenticated endpoint GET /api/v1/my/clinic-doctors returning only the
   secretary's ASSIGNED doctors — /clinic/doctor-list is on the public (no-JWT)
   firewall and cannot scope by user, so it would have leaked unbookable doctors.

3) Patient record delete. The `patients.delete` toggle was dead: every record
   delete (note/medical-record/attachment/call/message) was gated as
   `patients.update`. Mapped them to `patients.delete` so the toggle is honored
   and delete is controllable separately from edit.

New SecretaryAccessChecker::assignedClinicDoctorIds. Tests: doctor-list scoping,
patients.delete separation (denied/allowed). docs/api secretary.md +
appointment.md updated. Backend 286 + frontend 25 pass.

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

src/Secretary/Security/SecretaryAccessChecker.php

@@ -126,6 +126,25 @@ class SecretaryAccessChecker
         return $relation !== null && $this->permissions->can($relation, $resource, $action);
     }
 
+    /**
+     * idهای پزشکانِ تخصیص‌یافته به این منشی در این کلینیک — برای محدودکردنِ
+     * لیست‌هایی که پیش‌فرض همهٔ پزشکانِ کلینیک را برمی‌گردانند. اگر منشی نیست یا
+     * محیطش این کلینیک نیست → آرایهٔ خالی.
+     *
+     * @return int[]
+     */
+    public function assignedClinicDoctorIds(User $user, \App\Clinic\Entity\Clinic $clinic): array
+    {
+        if (!$user->hasRole('ROLE_SECRETARY')) {
+            return [];
+        }
+
+        return array_map(
+            static fn(\App\Doctor\Entity\Doctor $d) => $d->getId(),
+            $this->secretaryRepo->findDoctorsBySecretaryInClinic($user, $clinic),
+        );
+    }
+
     /**
      * آیا منشی در محیطِ فعالِ خود — که باید همین کلینیک باشد — مجاز به resource/action است؟
      * برای منابعِ کلینیک‌سطح مثل clinic_doctors که tenant لزوماً کلینیک است.