[FEATURE] Add Therapy and Therapy Type

[dcollie2]

Description

A therapy entry is a kind of log entry. It is a Log delegated type, and the Log carries the date.

Fields come from the journal's Therapy Log table (Section 6): Therapy, Date, Provider and Therapist's Name, Purpose/Goal, Activities, Recommendations/Practice Plan.

Therapy

• Is a Log delegated type (required) — the date lives on the Log
• Belongs to a TherapyType (required)
• Belongs to a provider — a Person, optional
• Provider name (String, optional) — free text, for when the provider isn't a Person record
• Purpose/goal (Text)
• Activities (Text)
• Recommendations/practice plan (Text)

Relationships: Log, TherapyType, Person (as provider)

The provider can be recorded either way: pick an existing person, or just type a name. Neither is required, and the user is not forced to create a Person record to log a therapy session.

belongs_to :provider, class_name: "Person", optional: true

TherapyType

Lookup table. TherapyType has many therapies.

• Name (String)
• Table is seeded with: physical, occupational, speech, psychological, other

UI

Standard scaffolding for Therapy and TherapyType, plus the pieces that make a therapy entry visible from the log:

• Index — follows the same tabular presentation pattern as app/views/prescriptions/index.html.erb. Copy that structure: the .table-scroll wrapper carrying tabindex="0", role="region" and an aria-label; <th scope="col"> headers; the first cell as <th scope="row"> linking to the show page; or_dash for optional values; table-note spans for secondary detail; and an empty-state paragraph when there are none. Columns: Date, Therapy type, Provider, Purpose/goal. Date order.
• Form — a provider select (optional, listing people) sitting alongside the free-text provider name field. Label them so it's obvious the user can do either.
• Display — one Provider value everywhere: the linked person's name when a provider is set, otherwise the free-text name, otherwise or_dash. Put that logic in a helper so the index, the show page and the log partial all agree.
• Register Therapy in Log's delegated_type list so it appears in the log type selector.
• Add a partial in app/views/therapies/ that renders a therapy entry's details in a log context.
• Modify the Log index and show to render that partial, dispatching on the loggable type — the same mechanism the Appointment ticket establishes. Keep the generic fallback intact.
• Add TherapyType to admin_sections in ApplicationHelper — it's reference data, same as medication types and forms.

Acceptance Criteria

• A user can add, view, edit and delete a therapy entry
• Saving requires a date and a therapy type
• The therapy type is selected from the seeded list
• TherapyType is seeded and manageable, and appears on /admin
• A therapy saves with a linked provider, with a typed provider name, or with neither
• Provider displays consistently across the index, the show page and the log partial: linked person's name, else free text, else a dash
• The index matches the prescriptions index pattern: scrollable labelled region, scoped table headers, row header linking to show, dashes for blanks, empty state
• The three long-form fields (purpose/goal, activities, recommendations/practice plan) are optional and render in full on the show page
• Therapy appears in the log type selector
• The log index and show render therapy details via the partial
• Log entries of a type with no partial still render via the fallback
• Model tests cover both models, including all three provider cases

Notes

• therapies is the Rails-correct table and view directory name for Therapy. Don't fight the inflector.
• Person has no display-name method today — app/views/people/_person.html.erb just renders first_name. This ticket needs a proper one (Person#full_name or similar); add it rather than string-concatenating in the view.
• The provider select lists all people for now. Scoping it to people whose relationship category is "provider" depends on Relationship/RelationshipCategory settling (see [BUG] Relationship needs to be a optional field on person #173), so don't build that here.
• The journal treats Purpose/Goal as one column; the ERD note lists "purpose, goal, activities, plan". Kept as one field to match the paper journal — split it only if someone using the app asks for it.
• Appointment's "Met/Spoke With" is the same problem and is still free text in that ticket. If this two-field pattern works, it should be applied there too.