Google-only login, add sign-out, remove self-service name editing

# Why?

**As a** repo owner
**I want** the web app's login page to only offer Google sign-in, a way to sign out, and no in-app way to edit a user's display name
**So that** Google Workspace remains the single source of truth for identity/name, matching how the org already manages accounts, and users aren't stuck signed in with no way to log out.

# What?

Follow-up to #306 (Next.js frontend epic, all 4 planned PRs shipped and merged). Reverses one specific decision from that epic (PR 4's self-service name editing) and closes two gaps found while manually testing the deployed app:

1. **No sign-out option exists anywhere in the UI today.**
2. **The login page shows both a Google button and an email/password form** (via `@aws-amplify/ui-react`'s ``) — the ask is Google-only for real users.
3. **Remove PR 4's `/profile` page** (self-service name editing via `updateUserAttributes`) — Google Workspace should own the display name; no in-app override.

# How? (sketch from an in-conversation design pass — not yet implemented)

- `web/app/login/page.tsx`: replace `` with a hand-built page that only calls `signInWithRedirect({ provider: "Google" })` (`aws-amplify/auth`), listening for the `Hub` `"signInWithRedirect"` event to redirect to `/browse`. `` has no documented way to show only social providers and hide the password form (confirmed via Amplify's own docs + a related open `amplify-js` GitHub issue), so it can't just be reconfigured.
- **New `web/app/test-login/page.tsx`**: a separate, unlinked page with a plain email/password form (`signIn({ username, password })`), used only by e2e tests (`rms.test@acts2.network` — Google's Hosted UI redirect isn't automatable in CI). This page **is** present in the deployed build and technically reachable if someone finds the URL. Accepted tradeoff: no real user ever has a Cognito password (accounts are only created via Google federation, restricted to `acts2.network` by the existing `PreSignUp` trigger), so there's nothing for anyone but the test account to sign in with here, even though Cognito's `loginWith.email` stays enabled at the pool level for this reason. (A `NEXT_PUBLIC_*` build-time env-var gate was considered instead, but a local build test showed Next.js 16/Turbopack did **not** reliably dead-code-eliminate the flag — the compiled JS did a runtime `process.env` lookup, not a literal boolean — so a separate unlinked route was chosen as more trustworthy.)
- `web/proxy.ts`: matcher excludes both `/login` and `/test-login` from the auth gate (both must be reachable while unauthenticated).
- **New `web/components/SignOutButton.tsx`**: small client component calling `signOut()` then redirecting to `/login`; added to `web/app/(protected)/layout.tsx`'s nav.
- `web/app/(protected)/layout.tsx`: remove the `/profile` nav link.
- **Delete** `web/app/(protected)/profile/` (`page.tsx` + `page.test.tsx`) and `web/e2e/profile.spec.ts` entirely.
- `amplify/auth/resource.ts`: doc-comment updates only (no functional change) explaining why `loginWith.email` stays `true`.
- `web/e2e/golden-path.spec.ts`, `web/e2e/reservations.spec.ts`: sign in via `/test-login` instead of `/login`'s now-removed password form; simplified locators since ``'s ambiguous-match chrome (Show password toggle, Google SSO button) no longer applies.

Per root `CLAUDE.md`'s testing policy: this needs `npx eslint .` / `npx next build` / `npx jest` passing locally, then `frontend-ci.yml` green (including e2e, which now exercises the new `/test-login` path) before merge.

# Additional context

Raised alongside a separate, **larger** question during the same conversation: what happens to a real user's `borrower`/`owner` history if their underlying Google account's email changes (e.g. on marriage)? Researched and confirmed Cognito's federated identity linking is keyed by the stable Google `sub` (auto-created username is `Google_<sub>`), not email — the person keeps signing into the same Cognito account, no lockout/duplicate-account risk. However, `ts-code/src/db/Schemas.ts`'s `borrower`/`owner` fields store the email **string** directly at write time, so historical records would keep showing the old email after a real change. Decided this should change: store the Cognito user's stable `sub` instead of email, with display name/email resolved live at render time. **This is explicitly out of scope for this issue** — it's a real backend schema change touching `MainSchema`/`ItemsSchema`/`ScheduleSchema` and every API that reads/writes those fields, plus a new sub-to-display-name resolution mechanism (a live `AdminGetUser` lookup per render would be slow/rate-limited, so it likely needs a cached user-directory table or similar). Tracked as a separate follow-up issue, needing its own dedicated planning session.</sub>