fix: convert appointment time from UTC to local time for display

[Cy-fox]

Closes #393

Appointment times were stored as UTC HH:mm strings by the API but rendered without any timezone conversion, causing them to appear 2 hours early for users in CEST (UTC+2). For example, an appointment at 10:30 CEST would show as 08:30.

Changes:

• parseTime in AccompanyingDetails helpers now converts a UTC HH:mm string to local time by setting UTC hours on a Date object and extracting via toTimeString, so the profile detail view shows the correct local time
• formatAccompanyingDate in OpportunityCard.helpers now formats the raw appointmentDate ISO string with date-fns and applies the same UTC-to-local conversion for appointmentTime, so the card view shows a human-readable date and the correct local time

[nadavosa]

PR #407 Review: Convert appointment time from UTC to local time for display

The display-only paths (OpportunityCard card view, AccompanyingDetailsDisplay) are correct. However there is a critical bug in the edit flow:

Critical: Round-trip data corruption in the edit form

parseTime in AccompanyingDetails/helpers.ts is used by getInitialFormValues to populate the React Hook Form default values, including appointmentTime. The <TimeInput> is pre-filled with the already-converted local time. On submit, AccompanyingDetails.tsx sends values.appointmentTime directly back to the API unchanged. This means:

1. API stores 08:30 (UTC)
2. parseTime converts it to 10:30 (CEST local)
3. User opens edit form — sees 10:30 ✓
4. User saves without changing — API receives 10:30 instead of 08:30
5. Next read: parseTime converts 10:30 → 12:30

Each save shifts the appointment time forward by the UTC offset. The fix should only convert for display, not for form state — either keep the raw UTC string in form state and convert only in display components, or convert back to UTC before submitting.

Medium: Duplicated conversion logic
The same 5-line UTC-to-local block appears in both OpportunityCard.helpers.tsx and AccompanyingDetails/helpers.ts. Should be extracted into a shared utility.

Low: toTimeString().slice(0, 5) relies on implementation-defined format
Works in all major browsers but String(d.getHours()).padStart(2, "0") + ":" + String(d.getMinutes()).padStart(2, "0") would be more explicit.

Info: DST awareness
When only HH:mm is stored without a date, DST transitions (summer vs winter) may produce a 1-hour discrepancy. Inherent limitation of the storage format.