Fix: Re-fetch feature flags with user address after authentication

## Problem

Feature flags are currently requested without the user's wallet address (or before the user is authenticated). This means:

- New users always receive the default/unauthenticated flag values, even after they log in.
- A/B tests that target specific wallet addresses are unreliable for new sessions — the explorer never re-evaluates flags with the authenticated identity.

## Expected Behavior

The feature flags system should reflect the authenticated user's identity so that:

1. Wallet-based A/B tests work correctly.
2. Flag values are consistent and accurate for logged-in users throughout the session.

## Proposed Solutions

**Option A — Fetch flags twice:**
- Fetch feature flags once at startup (without a user address, for anonymous/pre-auth state).
- Fetch again after the user completes authentication, passing the authenticated wallet address.

**Option B — Defer initial fetch until authenticated:**
- Wait for authentication before making the first feature flags request, so flags are always fetched with the user address.
- Handle the case where the user is never authenticated (guest mode) with a separate anonymous fetch.

Option A is preferred if early flags (before login) are needed for the login screen itself; Option B simplifies the flow when pre-auth flags are not required.

## Acceptance Criteria

- [ ] Feature flags are requested with the authenticated wallet address after login.
- [ ] A/B tests targeting specific wallets are applied correctly for new users.
- [ ] No regression for guest/anonymous users (flags still load without an address).
- [ ] Flags are not stale for the remainder of the session after authentication.