Feat/validade pontos

[andynnnfw]

No description provided.

[sousa7tz]

Revisão da task 31 (validade dos pontos).

A base está boa: o expire() trava o cartão com FOR UPDATE e confere a regra de novo antes de vencer, processa um cartão por transação, tem --dry-run, e rodar de novo não vence nada em dobro. Migration, schema.sql, schema_migrations, flash, operacao.md e testes vieram juntos. Calcular o vencimento em vez de gravar em expiration_date foi uma boa escolha.

Antes do merge

1. Saldo vencido continua valendo até o cron rodar. Depois que expires_at passa, a tela já mostra "Pontos vencidos em…", mas:

   • o resgate continua liberado;
   • um lançamento novo atualiza last_use_at e o saldo vencido volta a valer.

   Sugestão: em addPoints e redeem, vencer o saldo (mesma regra do EXPIRABLE) dentro da transação, antes de mexer no saldo. Se preferir algo mais simples, pelo menos bloquear o resgate quando a data já passou. Vale um teste de fluxo para cada caso.

2. composer analyse falha nesta branch. São os "might not be defined" de $expiryMonths e $expiryOptions em views/merchant/points-rule.php, que chegam pelo extract(). Como o CLAUDE.md pede, basta rodar composer analyse -- --generate-baseline e commitar o phpstan-baseline.neon. O CI não roda o PHPStan, por isso passou verde.

Menores

3. Loja inativa fica fora do vencimento, mas o prazo continua correndo. Quando o admin reativa a loja, todos os saldos antigos vencem na primeira execução. Se não for o comportamento desejado, uma opção é não contar o tempo em que a loja ficou inativa. Se for, vale registrar no operacao.md.
4. CLAUDE.md, seção Modelo de dados: a frase "toda mudança de saldo passa por addPoints / redeem / reverse" agora precisa incluir o expire.
5. Descrição do PR vazia e título fora do padrão. Sugestão: feat(pontos): validade dos pontos por loja, com a task 31 citada no corpo.

No Notion, a task 31 está como Em revisão com este PR, e o responsável é você.