docs: record local login recovery

docs/PROJECT_STATUS.md

@@ -107,6 +107,8 @@ Validação concluída em 4 de agosto de 2026:
 - backup PostgreSQL real em formato custom criado com checksum e validado por `pg_restore --list`;
 - restauro real numa base temporária: passou e confirmou 12 migrations antes da remoção automática;
 - smoke tests via Nginx: `/health/live` devolveu `ok` e `/health/ready` devolveu `ready`.
+- diagnóstico de login local: a base de desenvolvimento estava vazia apesar de migrada; `db:seed --force` repôs 2 utilizadores ativos, 5 perfis e 18 ativos fictícios, sem substituir dados existentes;
+- login real no browser validado com `demo@escola.pt`: redirecionou para `/dashboard` e não produziu erros de consola.
 
 ## Decisões pendentes do contexto institucional
 

docs/RUNBOOK.md

@@ -46,6 +46,22 @@ curl -s http://localhost:8000/login | grep 'data-server-rendered="true"'
 
 Se o endpoint Vite devolver um erro SSR, procurar primeiro componentes globais montados em `withApp` que chamem hooks Inertia como `usePage()`. Os elementos irmãos do argumento `app` não pertencem ao respetivo contexto; devem receber as propriedades através do segundo argumento de `withApp`.
 
+### Login regressa ao mesmo ecrã
+
+Um `POST /login` com resposta 302 seguido novamente de `/login` indica normalmente credenciais recusadas, não indisponibilidade do portal. Em desenvolvimento, confirmar primeiro se a base tem dados:
+
+```bash
+docker compose exec app php artisan tinker --execute="dump(App\\Models\\User::count());"
+```
+
+Se o resultado for zero e esta for a base local descartável, repor apenas os dados fictícios com:
+
+```bash
+docker compose exec app php artisan db:seed --force
+```
+
+As contas são `demo@escola.pt` e `admin@escola.pt`, ambas com a palavra-passe de desenvolvimento `password`. Nunca executar o seeder para corrigir acessos em produção; aí deve ser usado o processo administrativo de contas/recuperação.
+
 ## Atualização de código
 
 ```bash