Hospital & Pharmacy screens

Description

Where the patient is normally treated and where they normally collect
medication. The title says "screens" plural, and the two have different enough
fields that one list with a type toggle would likely read worse than two.
Deciding that is part of this ticket.

Repeatable-entry lists — people have more than one pharmacy, and often more than
one hospital.

Fields — need confirming, not sourced from any ADR

Hospital: name, address, phone, notes (e.g. "where I was treated in 2024").

Pharmacy: name, address, phone, notes.

If the field lists really are identical, that is an argument for one screen with
a type field — say which you chose and why.

Acceptance Criteria

• One-screen-or-two decision made and recorded in the PR description
• Add, edit, delete against the encrypted local database
• Built on the #49 component
• Ships its migration(s)
• Field lists 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.
• The pharmacy entry is likely wanted by the Medicine Diary work later (0014) — worth a glance before fixing the shape, though 0014 is still Open

QA

• Add one of each, relaunch, confirm persistence
• VoiceOver/TalkBack through add, edit and delete

Start by reading the #49 component props contract, docs/decisions/0014-medicine-diary-shape.md, and the migration tests around assertWellFormed and the in-memory SQLite harness. Confirm the fields with the product owner, coordinate the migration id, and record the one-screen-or-two decision in the PR. Done means encrypted add/edit/delete persistence, migration coverage, unit tests, and VoiceOver/TalkBack checks.