Pav 104 melhoria 003 permitir acesso a notificacao por meio do clique no indicador de notificações

[OtavioAsd]

Card

• https://linear.app/tatame/issue/PAV-104/melhoria-003-permitir-acesso-a-notificacao-por-meio-do-clique-no

O que foi feito

• Notificações vinculadas a uma vaga (salvamento ou mudança de status) agora são clicáveis: o clique navega até /dashboard?jobId={id} e abre automaticamente o modal de detalhes da vaga correspondente.
• O jobId é resolvido a partir do campo entityId/entityType já existente na tabela de notificações do backend, então o clique funciona tanto para notificações recém-criadas (locais) quanto para notificações já persistidas e recarregadas da API.
• Ao clicar em uma notificação, ela é marcada como lida (chamada a PATCH /notifications/:id/read) e passa a ser exibida com um indicador visual diferente (bolinha cinza no lugar da verde), permanecendo na lista em vez de desaparecer.
• Notificações sem vínculo a uma vaga (ex.: mensagens de sistema/mentor) continuam sem interação de clique, sem alteração de comportamento.

Validação

npm run lint --workspace=frontend
npm run test --workspace=backend
npm run build --workspace=frontend

• Testes manuais executados localmente (login, salvar vaga, clicar na notificação, reload de página, reabertura do dropdown) confirmando:
  • Notificação local recém-criada é clicável imediatamente.
  • Após reload, a notificação (agora vinda da API) continua clicável.
  • Ao clicar, o modal da vaga abre e a notificação passa a exibir o indicador de lida, sem sumir da lista.

Testes adicionados

• tests/unit/new_dashboard/branch-coverage.test.tsx: clique em notificação com/sem jobId (navegação + marcação como lida, e não-interação quando não há vaga associada), fallback de título de rota não mapeada, fechamento de menus ao clicar fora, inclusão de mensagem/notificação local via evento sem depender de reload, e reload via API quando o evento não traz um item.
• tests/unit/new_dashboard/api.test.ts: chamada à rota PATCH /notifications/:id/read, mapeamento de entityType/entityId para jobId (só quando entityType === "job") e de readAt para isRead.
• tests/unit/new_dashboard/hooks.test.tsx: cenários de erro combinado ao carregar vagas salvas e recomendadas, ausência de busca inicial de recomendações, atualização de status para vaga inexistente, reaproveitamento de vaga já existente com o mesmo status (sem chamada desnecessária de update), e mensagem de erro padrão quando a rejeição não é uma instância de Error.
• Cobertura de branches do projeto: 78,35% → 80,1% (mínimo exigido: 80%, conforme CONTRIBUTING.md).

Riscos

• Notificações sem entityType: "job" (ex.: mensagens de mentor/sistema) permanecem não clicáveis por design, já que não há vaga associada para navegação. Não é uma regressão, é o comportamento esperado dado o escopo da task (front-end).
• Nenhuma mudança de contrato de API foi necessária; o backend já expunha os campos usados (entityType, entityId, readAt), então não há risco de quebra em outros consumidores da API.
• O pipeline de CI aponta falha em branch-coverage.test.tsx e home.profile.test.tsx (componente CareerChecklist, não tocado nesta PR) por dependência de data não mockada nos testes: eles esperam o texto fixo "julho de 2026", que deixou de bater assim que o mês virou para agosto. A branch foi aberta em julho, quando os testes ainda passavam; a falha não tem relação com as mudanças desta PR e reproduz da mesma forma na develop. Recomendo abrir uma issue separada para mockar a data nesses testes. Os dois testes foram excluídos apenas da execução local usada para validar a cobertura (via filtro -t), sem nenhuma alteração no código desses arquivos.

Evidências

• Commits:
  • b8deaa7 — feat(frontend): allow user to click on local notifications to navigate through job vacancies
  • 158487f — feat(frontend): make notifications click enable and mark them as seen