Fix snake_case/camelCase mismatch in modern-bias page (2 TS errors)

## Summary

The `modern-bias` page has **2 TypeScript errors** caused by a snake_case/camelCase mismatch between the FastAPI backend (which serializes Python field names as `snake_case`) and the frontend TypeScript types (which expect `camelCase`). Pick the right approach, fix the mismatch, and you'll have learned how this codebase crosses the Python <-> TypeScript boundary.

## Background

- **Backend:** FastAPI + Pydantic. Conventional Python serializes fields as `snake_case`: `total_tests`, `gdpr_compliant`, `evaluation_time`.
- **Frontend:** TypeScript + React. Conventional JS expects `camelCase`: `totalTests`, `gdprCompliant`, `evaluationTime`.
- A previous refactor renamed the frontend type definitions to `camelCase` but did not add a translation layer at the API boundary, so the runtime payload still has snake_case keys while TypeScript thinks it should have camelCase. The compiler catches this - runtime would fail silently with `undefined` reads.

## The Errors

```
apps/frontend/src/app/(dashboard)/modern-bias/page.tsx(268,9):
error TS2739: Type '{ total_tests: number; tests_passed: number; tests_failed: number;
overall_bias_rate: number; evaluation_time?: string }'
is missing the following properties from type
'{ totalTests: number; testsPassed: number; testsFailed: number;
overallBiasRate: number; evaluationTime?: string }':
totalTests, testsPassed, testsFailed, overallBiasRate

apps/frontend/src/app/(dashboard)/modern-bias/page.tsx(271,9):
error TS2559: Type '{ gdpr_compliant?: boolean; ai_act_compliant?: boolean;
fairness_score?: number }'
has no properties in common with type
'{ gdprCompliant?: boolean; aiActCompliant?: boolean; fairnessScore?: number }'
```

Both errors are in the body of `handleRunEvaluation` (around lines 218-340) where `results.evaluation_summary` and `results.compliance_status` are passed to a typed function that expects camelCase.

## Two Approaches - Please Comment Before Starting

### Approach A - Translate at the boundary (recommended, ~2-3h)

Add a `snakeToCamel` helper inside the api-client (or a small `apps/frontend/src/lib/api/case-transform.ts`) that recursively walks API responses and renames keys. Wire it into the bias evaluation hook so consumers always see `camelCase`.

**Pros:** Frontend code stays idiomatic TypeScript. Future API additions get conversion for free.
**Cons:** Touches `api-client.ts` (or adds a new helper imported by the hook). Needs a couple of unit tests.

### Approach B - Make the frontend types match snake_case (~30 min)

Change the type definitions used by `modern-bias/page.tsx` from `totalTests` -> `total_tests`, etc. The page already does some manual mapping in `handleRunEvaluation` - that mapping can be deleted because the shapes will be identical.

**Pros:** Smallest possible diff.
**Cons:** Non-idiomatic TypeScript. Will surprise future contributors who expect camelCase frontend types. Doesn't fix the underlying convention drift.

**Please comment on this issue with which approach you want to take *before* starting work.** A maintainer will respond within 48 hours to confirm.

## Files Involved

- **Read first to understand context:**
- `apps/frontend/src/app/(dashboard)/modern-bias/page.tsx` (lines 75-340 - the hook + the report generators)
- `apps/frontend/src/lib/api/api-client.ts` (the wrapper you may extend in Approach A)

- **Files you'll modify (Approach A):**
- `apps/frontend/src/lib/api/api-client.ts` *or* a new `case-transform.ts`
- `apps/frontend/src/app/(dashboard)/modern-bias/page.tsx` (delete the manual snake->camel remapping in the report generator calls now that the hook returns camelCase)
- Tests under `apps/frontend/src/lib/api/__tests__/` (add 1-2 unit tests for the transformer)

- **Files you'll modify (Approach B):**
- `apps/frontend/src/app/(dashboard)/modern-bias/page.tsx` (the inline type definitions for `EvaluationSummary` and `ComplianceStatus` - and the type imported by `generatePDFReport`/`generateDOCXReport`)
- `apps/frontend/src/lib/export/json-export.ts` (the `BiasEvaluationPDFData` type)

## Acceptance Criteria

- [ ] `cd apps/frontend && npx tsc --noEmit` reports zero errors at `modern-bias/page.tsx:268` and `:271`
- [ ] No `as any` casts
- [ ] **If Approach A:** Includes 1-2 unit tests for the transformer (basic case + nested object case)
- [ ] **If Approach B:** Type renames are consistent - every consumer of `BiasEvaluationPDFData` and the eval-summary type uses snake_case
- [ ] Manual smoke test (optional): with a backend running, navigate to `/dashboard/modern-bias`, run an evaluation, and verify the PDF/DOCX/JSON export buttons still produce correct output

## How to Reproduce

```bash
git clone https://github.com/adhit-r/fairmind.git
cd fairmind/apps/frontend
npm install
npx tsc --noEmit
```

Errors at `modern-bias/page.tsx:268` and `:271` should appear.

## Estimated Effort

- **Approach A:** 2-3 hours (helper + tests + cleanup)
- **Approach B:** 30 minutes (mechanical rename)

Both are welcome - pick based on your experience level.

## Why This Is a Good First Issue

- **Tightly scoped.** Two errors, one file (Approach B) or one new helper (Approach A).
- **Educational.** You'll learn how a Python/TypeScript stack handles the case-naming impedance mismatch.
- **Has a clear right answer** once you pick the approach.
- **Maintainer support.** Comment on this issue with questions and a maintainer will respond within 48 hours.

## Help / Questions

Comment on this issue to claim it (say "I'd like to take this" + which approach) before starting, so we don't have duplicate work. A maintainer will confirm within 48 hours.