fix(frontend): make the participants View link reach a real page

[hanaCasey]

Summary

The View button on every card in the hackathon participants page was dead. ParticipantCard defaults profileDetailsHref to '#', and the participants page passed #participant-{id} — a same-page anchor to an element that exists nowhere on the page — so every click went nowhere.

View is meant to open that participant's registration answers (affiliation, diet, skills) — the data an organizer needs for catering and check-in. The backend already fully supports this: HackathonService.GetRegistrationResponse takes an optional user_id, returns the caller's own answers when absent, and requires hackathon Write (organizer) to read anyone else's — else PermissionDenied. The self-service /register/[id] route already renders exactly this data for the caller (editable, pre-filled), so this extends that route rather than adding a new one or a new RPC.

Changes

• /register/[id] now accepts an optional ?userId=. When present it fetches that person's answers via getRegistrationResponse({ hackathonId, userId }), renders them read-only (values as text, consent boxes shown but disabled, no submit button), and titles the page with the target's name (read off the members already returned by hackathon.get — no new RPC). A not-yet-submitted target shows "No response yet." rather than a blank editable form. Permission is left entirely to the backend: PERMISSION_DENIED → 403, NOT_FOUND → 404, following the repo's error-translation convention.
• Participants page points View at /register/{id} for your own row (editable, no query param) and /register/{id}?userId={id} for others. It offers the cross-participant link only to managers (data.mayManage) — matching how every other organizer-only affordance on this page is hidden rather than left to fail, since a plain member clicking it would deterministically 403.
• ParticipantCard omits the View link entirely when no profileDetailsHref is given (the default is now undefined, not '#').

No backend or proto changes — the RPC and its permission check already existed.

Test plan

• pnpm run check (svelte-check): 0 errors (5 pre-existing warnings in untouched files).
• eslint on the 5 touched files: no new errors (2 pre-existing no-navigation-without-resolve on the /dashboard links already in register/+page.svelte).
• Manual click-through against the running dev stack (Playwright/Firefox, seeded DB — "Spring DAta Hackagon", participant bob who has a submitted form):
  • As hackagon-admin (organizer via global Admin): the participant card's View link resolves to /register/{id}?userId={bob}, navigates, and renders bob's real answer read-only with no Save/Submit button.
  • Direct /register/{id}?userId={bob} renders bob's answers read-only.
  • A participant with no submitted form renders "{name}'s registration … No response yet."
  • Own editable form (/register/{id}, no userId) still shows the Save/Submit button.
  • Backend negative case confirmed over gRPC: a non-organizer reading another user's user_id gets PermissionDenied (→ 403 in the UI).