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/0009-dental-service-attributes-live-in-an-extension-table.md

@@ -0,0 +1,15 @@
+# Dental attributes of a service live in an extension table, not on ServiceItem
+
+Whether a service is priced per tooth, per surface or per canal — and whether booking it must ask for a
+tooth at all — is dental-only knowledge, but `ServiceItem` is shared by every practice domain. Those
+attributes therefore sit in a one-to-one `dental_service_profiles` row in the Dental context, keyed by
+`service_item_id`, so a beauty clinic carries no dental columns and the next domain is not invited to add
+its own set to the shared table. The cost is a join whenever the dental profile is needed, which is the
+same pattern the codebase already uses elsewhere.
+
+## Consequences
+
+The reverse choice was made deliberately one level down: the tooth and surfaces a visit line was actually
+billed for are columns on `SessionService` itself, because that row is the clinical and financial record
+of the visit rather than shared configuration, and splitting it would allow a billed line to lose its
+target unnoticed.