Standardize Date/Time Handling Across Frontend to Eliminate Timezone Regressions

## Description

The frontend currently uses mixed date formatting approaches: some places enforce UTC, while others use browser-local timezone implicitly. This inconsistency can reintroduce off-by-one date bugs and mismatched date displays across pages.

This is a cross-cutting issue: even when one page is fixed, similar bugs can still appear elsewhere unless date handling is standardized.

## Problem
There is no single source of truth for date rendering rules in the frontend.

### Current state
- Shared utility with UTC formatting exists:
- `frontend/src/utils/dateFormatter.ts`
- Multiple components still format dates locally with direct `new Date(...).toLocaleDateString()` / `toLocaleString()` usage:
- `frontend/src/components/ModuleCard.tsx`
- `frontend/src/components/MentorshipPullRequest.tsx`
- `frontend/src/components/HealthMetrics.tsx`
- `frontend/src/components/MetricsCard.tsx`
- `frontend/src/app/my/mentorship/programs/[programKey]/modules/[moduleKey]/issues/[issueId]/page.tsx`
- and other similar call sites

## Impact
1. Same backend date can render differently in different pages.
2. Users in timezones behind UTC can see previous-day dates for calendar-oriented fields.
3. Regressions are likely to repeat because formatting policy is not centralized.

## Proposed Solution
### 1) Define and document date rendering policy
- **Calendar dates** (program/module/event start/end): render in **UTC**.
- **Activity timestamps** (createdAt/updatedAt, logs): render in **local timezone** (or clearly labeled timezone).

### 2) Extend shared utility layer
Add standardized helpers in `frontend/src/utils/dateFormatter.ts` (or dedicated date utils module), for example:
- `formatUtcDate(input)`
- `formatUtcDateRange(start, end)`
- `formatLocalDateTime(input)`
- `formatDuration(start, end)`

### 3) Migrate call sites
Refactor components/pages to remove inline date formatting and use shared helpers instead.

### 4) Add regression tests
- Unit tests for utility functions
- Component tests for key pages
- Timezone-mocked test matrix (e.g., `UTC`, `America/New_York`, `Asia/Kolkata`)

## Suggested Implementation Plan
1. Audit and list all direct `new Date(...).toLocaleDateString()` / `toLocaleString()` usages.
2. Group by semantic type (calendar date vs timestamp).
3. Replace with shared utility methods.
4. Add/adjust tests.
5. Add lightweight docs note in contributing/frontend guidelines.

## Acceptance Criteria
- [ ] No direct date rendering logic remains in target components (except approved edge cases).
- [ ] Calendar-based dates render consistently across all pages in UTC.
- [ ] Timestamp-based values follow one documented policy.
- [ ] Tests pass under at least 3 mocked timezones (`UTC`, `America/New_York`, `Asia/Kolkata`).
- [ ] Existing date-related tests updated and passing.

## Non-Goals
- Backend schema changes
- Historical data migration
- UI redesign unrelated to date rendering behavior

## Are you going to work on fixing this?
- [x] Yes
- [ ] No