Health Care Providers — add/edit/delete list

Description

The clinicians involved in the patient's care. Repeatable-entry list, same
pattern as Contacts.

The existing one-line body names four kinds of provider — PCP, specialists,
PT/OT, social worker. That is a role dimension, not four separate screens: one
list where each entry records what kind of provider it is.

Fields — need confirming, not sourced from any ADR

• Name
• Role / specialty (PCP, specialist, PT/OT, social worker, other)
• Practice or organisation
• Phone
• Address
• Notes

Whether role is free text or a fixed set is worth deciding here, because #37 and
#43 will face the same question.

Acceptance Criteria

• Add, edit, delete against the encrypted local database
• Built on the #49 component; no field logic specific to this screen in the shared code
• Ships its migration, appended to MIGRATIONS — never edit a merged entry
• Field list confirmed with the product owner before merge
• WCAG-aligned; copy neutral per 0004
• Covered by unit tests

Additional Info and Resources

• Not blocked on #118 finishing — only on its props contract. The repository
  config, the migration and their tests can be written first against the
  in-memory SQLite harness; the screen fills in behind once #118 publishes the
  component's shape.
• Coordinate your migration id before you start. assertWellFormed requires
  them contiguous from 1, so parallel PRs each adding "migration 1" all conflict
  after the first one merges. Renumbering an unmerged entry is fine — the "never
  edit a merged entry" rule only applies once it has shipped.
• Sorting: the repository returns oldest-first with an id tiebreak. If providers should sort by name instead, that is a change to the shared layer — raise it rather than sorting in the screen

QA

• Add three providers of different roles, relaunch, confirm order and content
• Delete the middle one, confirm the other two are untouched
• VoiceOver/TalkBack through add, edit and delete

Start with the Contacts pattern and the #49 shared component contract, then inspect MIGRATIONS and the in-memory SQLite harness. Confirm the fields and role representation with the product owner, coordinate the migration id, and wait for or use the props contract from #118. Done means CRUD persistence, migration and unit tests, accessibility checks, and the listed QA flow pass.