Add dental module phase 4 and phase 5 documentation, including treatment estimates, clinical operations, and preset content

- Introduced phase 4 documentation detailing treatment estimates, data models, state machines, API endpoints, and new dashboard metrics.
- Added phase 5 documentation covering consumables, lab operations, periodontal charts, sterilization cycles, clinical images, and a checklist for professional review.
- Created a preset content document outlining default dental service packages and protocols for clinics.

docs/adr/0007-practice-domain-is-tenant-level.md

@@ -0,0 +1,13 @@
+# Practice domain belongs to the tenant, not only to the clinic
+
+`practice_domain_id` originally lived on `clinics`, but every piece of operational data in this
+codebase is owned by an `(entity_type, entity_id)` pair where `entity_type` is `doctor` or `clinic`.
+A solo practice is a `doctor` tenant, so it could never declare a practice domain at all — the beauty
+domain has the same hole, it simply had not been noticed. The column is therefore added to `doctors`
+as well and read through a single `PracticeDomainResolver` that takes an `EntityContext`, so no
+caller has to know which kind of tenant it is looking at.
+
+## Considered Options
+
+Letting a doctor inherit the domain of a clinic they work at was rejected: a doctor with no clinic
+would stay domainless, and a doctor working at two clinics with different domains would be ambiguous.