FavoritesProvider ignores auth loading; one frame where a click can duplicate a favorite

Part of #1707. Found in the review of #1689.

## Problem

`packages/shared/providers/favorites/provider.tsx` (around line 99) doesn't read `useAuth().isLoading`. While auth is still loading, the effect takes the `!isAuthenticated` branch and sets `favorites = []`, `isLoading = false`. When `/auth/me` resolves, `setUser` and `setIsLoading(false)` batch into one render where the provider's `isLoading` is still `false` and `keysRef` is empty; `setIsLoading(true)` only runs in the passive effect at line 104.

## Failure scenario

There is one committed render after auth resolves where every `FavoriteButton` / `FavoriteCell` is enabled and unfilled. A click in that frame calls `createFavorite(X)` for an entity that is already saved. If that request resolves after the initial `getFavorites`, `setFavorites(current => [favorite, ...current])` (line 143) lists X twice: duplicate React key in `FavoritesSection`, count off by one until reload.

## Suggested fix

Gate the effect on the auth `isLoading` flag, the way `useUserResource` already does.

Start in packages/shared/providers/favorites/provider.tsx around lines 99, 104, and 143, then compare its auth handling with useUserResource. Verify the provider waits for auth loading before settling favorites and that no committed frame enables an unfilled favorite, preventing duplicate entries and React keys.

Written by the indexing model from the issue text.