[Frontend] Add route-level authorization tests for every protected page

## Problem

Protection behavior is not systematically verified across admin, wallet, records, settings, and analytics routes.

## Relevant code

`src/components/ProtectedRoute.tsx, src/pages`

## Proposed scope

Create a route matrix covering guest, user, staff, and admin states and assert both UI and API denial behavior.

## Acceptance criteria

- [ ] The reported behavior is reproduced or characterized with a focused automated test before the fix.
- [ ] The implementation satisfies the proposed scope without weakening TypeScript, lint, authorization, privacy, or error handling.
- [ ] Success, empty/loading where applicable, failure, and boundary cases are covered.
- [ ] Existing related tests pass and new regression coverage is included.
- [ ] User-facing behavior remains accessible by keyboard and at mobile viewport sizes where UI is affected.
- [ ] Documentation is updated when the change alters configuration, contracts, security assumptions, or contributor workflow.

## Contributor notes

Base the work on the latest `main` branch. Keep unrelated refactors out of the pull request and include screenshots or recordings for visible changes. Never use real pet, medical, contact, wallet, or credential data in fixtures.

Start with src/components/ProtectedRoute.tsx and the route entries under src/pages to identify every protected page and its required role. Build a guest, user, staff, and admin route matrix, then verify both rendered access behavior and API denial behavior using the repository’s existing test patterns. Done means focused regression coverage for success, denial, loading, empty, failure, and boundary cases without weakening authorization.

Written by the indexing model from the issue text.