fix(portal-shell): send withCredentials on /me so the session cookie crosses SPA→BFF in dev (#114)

## Summary

Manual smoke after PR #113 surfaced a dev-only bug: after `/auth/callback` the BFF correctly sets the `portal_session` cookie and redirects to the SPA, but the SPA's next call to `/api/auth/me` comes back **401 with no `cookie:` header at all**. The user lands "back at the portal" but the header still shows "Sign in".

**Root cause.** Angular's `HttpClient` via `withFetch()` inherits `fetch`'s default `credentials: 'same-origin'`. In dev, `localhost:4200` (SPA) → `localhost:3000` (BFF) is cross-origin (different ports), so the browser drops the session cookie on the way out. SameSite=Lax is a red herring: both URLs share the registrable domain, so the cookie is still same-site — what was missing was opting the fetch into credentials.

**Fix.** Per-call `withCredentials: true` on the /me request. Only /me needs cookies today; login/logout are full-page navigations through `window.location`, which the browser hydrates with cookies regardless. A global `HttpInterceptor` will be the right abstraction once other authenticated BFF endpoints exist — premature for one consumer.

**BFF side was already correct.** `enableCors({ credentials: true })` in `main.ts`. Nothing to change.

A new spec pins `withCredentials === true` on the /me request so a future refactor can't silently drop the flag and reintroduce the bug.

## Test plan

- [x] `pnpm nx test feature-auth` → **9/9 pass** (was 8 before; +1 spec pinning the credentials flag).
- [x] `pnpm nx test portal-shell` → **32/32 pass**.
- [x] `pnpm nx lint feature-auth portal-shell` → clean.
- [x] `pnpm nx build portal-shell` → clean.
- [ ] Manual smoke against the running BFF: anonymous landing → click "Sign in" → Entra → callback → SPA lands with avatar + display name in the header (the very last step that failed before this fix).

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #114

libs/feature/auth/src/lib/auth.service.spec.ts

@@ -62,6 +62,18 @@ describe('AuthService', () => {
       expect(service.isLoading()).toBe(false);
     });
 
+    it('issues /me with withCredentials so the session cookie crosses the SPA→BFF origin gap', () => {
+      const { http } = setup();
+      const req = http.expectOne(ME_URL);
+      // Without this, `fetch`'s default `credentials: 'same-origin'`
+      // would suppress the session cookie on the cross-origin
+      // (localhost:4200 → localhost:3000) request and /me would
+      // always answer 401 in dev. Verified manually against the BFF
+      // log on 2026-05-12.
+      expect(req.request.withCredentials).toBe(true);
+      req.flush({ error: 'unauthenticated' }, { status: 401, statusText: 'Unauthorized' });
+    });
+
     it('transitions to anonymous on 401', async () => {
       const { service, http } = setup();
       http

libs/feature/auth/src/lib/auth.service.ts

@@ -58,7 +58,18 @@ export class AuthService {
    */
   async refresh(): Promise<void> {
     try {
-      const user = await firstValueFrom(this.http.get<CurrentUser>(this.meUrl));
+      // `withCredentials: true` is mandatory: the SPA at
+      // http://localhost:4200 calls the BFF at http://localhost:3000 —
+      // different origins, so `fetch`'s default `credentials:
+      // 'same-origin'` would drop the `__Host-portal_session` cookie
+      // and /me would always answer 401. Production (single origin
+      // behind the same edge) doesn't need it but it's harmless there.
+      // CORS on the BFF side already allows credentials
+      // (`apps/portal-bff/src/main.ts` → `enableCors({ credentials:
+      // true })`).
+      const user = await firstValueFrom(
+        this.http.get<CurrentUser>(this.meUrl, { withCredentials: true }),
+      );
       this._state.set({ kind: 'authenticated', user });
     } catch (err) {
       this._state.set(toErrorState(err));