Reestruturação do fluxo Baita RBS

🆕 Implementado e mesclado em main. Motivação: o modal de "escolha de fluxo" (3 opções) misturava ações fundamentalmente diferentes, e cadastrar-se após validar um código exigia sair do modal e perder contexto.

Header (3 estados)

• Não logado: dois botões — "Ativar código" (primário, abre o modal direto no step CODE_INPUT) e "Entrar/Cadastrar" (link para /assinar).
• Logado com acesso ativo: nenhum botão de ativação/assinatura.
• Logado com acesso expirado: botão "Ativar código" que abre o modal no step CHOOSE_FLOW, agora com 2 opções ("Inserir código" e "Assinar online").

Seletor "Já é cliente Baita?"

Componente reutilizável, sem lógica de navegação embutida (recebe callbacks), usado em 2 contextos:

• Em /assinar (novo step 0, progress bar passa de 5 para 6 segmentos): "Já sou cliente Baita" → avança para o CPF check; "Não sou cliente" → /cadastro; "Já tenho conta" → /login.
• No modal de assinatura do /eu (aberto via ?openSubscription=true): "Já sou cliente" → mostra plano + pagamento direto; "Não sou cliente" → fluxo NewSubscriptionModal padrão.

Cadastro inline no modal de código

Não-logado que valida um código vê "Entrar" ou "Cadastrar". "Cadastrar" abre 2 novos steps dentro do próprio modal (REGISTER_PERSONAL, REGISTER_ADDRESS), reaproveitando os schemas de /assinar. Ao submeter: POST /user (sem plano/pagamento) → login automático (cookies via nookies) → POST /accesscodes/activate → redirect por tipo de código (onlyLottery → /sorteios; lotteryAndIncentives → /inicio).

Refatoração dos componentes de pagamento

Os componentes eram um único bloco com 6 a 10 if (isSubscribeMode) cobrindo 3 contextos. Foram separados em orquestradores por fluxo: NewUserPaymentStep / NewUserPixCodeStep (zero props, leem do store Zustand) e ExistingUserPaymentStep / ExistingUserPixCodeStep (recebem planId/onSuccess via props e gerenciam pixPaymentData localmente). O campo registerMode foi removido do store.