Add Auth-owned product roadmap to README

Captures the Auth slices of the cross-service product roadmap:
username + public-profile opt-in, friends graph, email/notification
preferences, invitation system enhancements, and GDPR delete/export.
Cross-links to the umbrella roadmap in ToBePlayed-Deployment.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

readme.md

@@ -101,3 +101,46 @@ Tracking known work that is not yet implemented. Each item is independently acti
 ### Testing
 
 - The abstract test bases under `auth_service.shared.test` already cover unit / integration / persistence / WebMvc slices. Continue adding controller-level `AbstractWebMvcTest` coverage for any new endpoint and persistence-layer tests for any new repository.
+
+## 🎯 Product Roadmap (Auth-owned slices)
+
+The full cross-service product roadmap lives in `ToBePlayed-Deployment/README.md`. This section lists only the slices that land in Auth.
+
+### 1. Username + public-profile opt-in
+
+The public profile feature (`tbp.andreas-dahm.eu/u/<username>`) requires:
+
+- **Unique, human-readable username** distinct from email. Schema: add `username` column on `users` with a unique index and a Flyway migration. Validation: 3–30 chars, `[a-z0-9_-]`, case-insensitive uniqueness.
+- **`profile_public` flag** (boolean, default `false`) on `users`. Exposed via `PUT /api/users/settings`.
+- New endpoint: `GET /api/public/users/{username}` returning `{ username, displayName, steamId?, joinedAt }` — the public-facing identity contract that Core's profile endpoint can compose with.
+
+### 2. Friends / social graph
+
+Once usernames exist:
+
+- Schema: `user_friendship(user_id, friend_id, status, requested_at, accepted_at)` with `status` in `PENDING / ACCEPTED / BLOCKED`. Symmetric pair or single-row with a canonical ordering — pick one and stick with it.
+- Endpoints: `POST /api/users/me/friends?username=...` (request), `POST /api/users/me/friends/{id}/accept`, `DELETE /api/users/me/friends/{id}`, `GET /api/users/me/friends`.
+- Optional: discovery via the Steam friends API (Auth holds the `steam_id`; the friends list call itself can live in Core's `steam_adapter`, with Auth resolving Steam IDs back to TBP users).
+
+### 3. Email-driven retention
+
+The weekly digest, sale alerts, and friend-request notifications all need email infrastructure:
+
+- Spring's `JavaMailSender` + templating (Thymeleaf or plain interpolation). Configure SMTP via env vars (see Deployment roadmap).
+- Per-user notification preferences: `notify_digest_weekly`, `notify_sale_alerts`, `notify_friend_requests` — all booleans on `users` with sensible defaults.
+- Endpoint to render `/api/users/me/notification-preferences` and update via `PUT`.
+- Triggered by either Core scheduled jobs (digest, sale alerts) calling an internal Auth endpoint, or by a shared message queue if/when one is introduced.
+
+### 4. Invitation system enhancements
+
+Today registration validates an `INVALID_INVITATION_CODE` — so invites already exist. Worth surfacing:
+
+- Endpoint: `POST /api/users/me/invitations` to generate a single-use code (rate-limited, expires after N days). Used for friend invites and onboarding referrals.
+- Endpoint: `GET /api/users/me/invitations` to list outstanding codes.
+- Optional: tie invitation acceptance to an auto-friend-request so referred users are already connected on first login.
+
+### 5. Account deletion / GDPR
+
+- `DELETE /api/users/me` that soft-deletes (sets `deleted_at`, anonymises PII, keeps the row for foreign-key integrity), or hard-deletes with cascade depending on policy.
+- Data export endpoint: `GET /api/users/me/export` returning a downloadable JSON bundle of everything Auth knows about the user. Core should expose an equivalent and the Frontend can stitch them.
+- Document the data-retention policy here once decided.