Persist onboarding progress

[Ezeh20]

Summary

Closes #84

Adds persisted onboarding progress and a consent history model.

• Onboarding (OnboardingProgress, 1:1 with User): version, currentStep, completedSteps[], status, timestamps. Resuming (GET /onboarding) upserts-on-read so it's deterministic on first and every subsequent call. Saving a step (POST /onboarding/steps) is idempotent — steps dedupe via Set, and the record refuses further writes once completed (terminal state).
• Consent (ConsentRecord, many-to-one with User): append-only — every grant/withdraw inserts a new row instead of mutating one, so the row history is the audit trail. Each row carries purpose, required (computed at write time from REQUIRED_CONSENT_PURPOSES, frozen onto the row), policyVersion, status, source, grantedAt/withdrawnAt.
• Transitions: a generic canTransition<S>(map, from, to) guard (src/utils/transitions.ts) — a minimal, scoped stand-in for the still-unbuilt "Introduce Typed Status Enums and Transition Guards" dependency, sized to what this feature needs rather than blocking on that work.
• Completion gating: OnboardingService.complete() requires all REQUIRED_ONBOARDING_STEPS present and all REQUIRED_CONSENT_PURPOSES currently granted (via ConsentService.hasAllRequiredGranted) before allowing the in_progress → completed transition.
• Required vs. optional kept distinct: ConsentService.withdraw blocks required purposes outright (required-cannot-withdraw); optional purposes withdraw freely, carrying forward the last known policyVersion.
• Routes: GET /onboarding, POST /onboarding/steps, POST /onboarding/complete, GET /consents, GET /consents/history, POST /consents/grant, POST /consents/withdraw.

Verification evidence

• Migration: prisma/migrations/20260730130000_add_onboarding_and_consent/migration.sql — onboarding_progress and consent_records tables, FKs to users, indexes on status and (userId, purpose, createdAt).
• Transition matrix: