Section-by-section progress indicator

Description

Shows how far through the journal a user is, section by section, so completing
one section feels like progress rather than a fraction of an unfinished whole.
Directly serves the reduce-cognitive-load principle: the record is long, and
someone filling it in during a hard week needs to be able to stop.

The one Phase 1 ticket that needs neither the storage layer nor a native
build, if it is built as a presentational component taking completion state as
props. That makes it the right ticket for anyone without Xcode or Android
Studio, and the right ticket to start before #118 lands.

Scope

• A presentational component: given a list of sections and their completion
  state, render progress
• Wiring it to real data is a follow-up, once there are sections to measure
• What "complete" means needs deciding: any field filled, all fields filled,
  or explicitly marked done by the user. The third is the most honest for a
  journal where many fields legitimately stay empty — but that is a product call

Acceptance Criteria

• Completion definition agreed with the product owner and recorded
• Presentational component with no direct database access, driven by props
• Progress never reads as failure — no red, no scolding, no "incomplete" framing
• Communicated by more than colour: text or shape carries the same information
• Screen reader announces progress meaningfully rather than as a bare percentage
• Covered by unit tests, with no native build required to run them

Additional Info and Resources

• 0004 — a caregiver may be filling this in for someone else, so avoid copy that implies the user's own diligence
• Tone matters here more than anywhere else in Phase 1. This is the component most able to make someone feel behind

QA

• Render at 0%, part-way and 100%, confirm all three read as encouraging
• Confirm progress is distinguishable in greyscale
• Listen to it with VoiceOver/TalkBack and confirm the announcement is useful

Read docs/decisions/0004-primary-user-caregiver-role.md, then inspect the existing presentational component patterns and unit-test setup. Resolve the completion definition with the product owner before implementation. Done means a prop-driven component with encouraging, non-colour progress communication, meaningful screen-reader output, coverage for 0%, partial, and 100%, and no native build requirement.