ci: make lint and type checks fail the build

[Guajir0-code]

Problema

O workflow linter passa independentemente do que encontra. Ele roda as variantes que reescrevem os arquivos, e essas sempre saem com código 0.

Evidência

- name: Run Pint
  run: vendor/bin/pint          # corrige e sai 0

- name: Format Frontend
  run: npm run format           # prettier --write, sai 0

- name: Lint Frontend
  run: npm run lint             # eslint . --fix

As correções são aplicadas dentro do runner e descartadas quando ele é destruído — o passo que faria o commit está comentado:

# - name: Commit Changes
#   uses: stefanzweifel/git-auto-commit-action@v5

Ou seja: o job nunca reprova por estilo e nada do que ele corrige chega ao repositório.

O estado real de main hoje, medido rodando as variantes de verificação:

Ferramenta	Resultado em main
pint --test	2 arquivos fora do padrão
prettier --check	15 arquivos fora do padrão
eslint	1 erro (import não usado em TagPosts.vue)
vue-tsc	limpo

Tudo isso com o badge verde.

Solução

1. Trocar por variantes que reportam

- name: Check PHP Code Style
  run: vendor/bin/pint --test

- name: Check Frontend Formatting
  run: npm run format:check

- name: Lint Frontend
  run: npm run lint:check

- name: Type Check Frontend
  run: npm run type-check

format:check já existia no package.json e nunca era chamado. lint:check e type-check são novos:

"lint:check": "eslint .",
"type-check": "vue-tsc --noEmit"

vue-tsc já estava nas devDependencies desde o início do projeto, mas nunca foi executado por nenhum script nem pelo CI.

2. Instalar Node de forma reprodutível

O job não tinha actions/setup-node — dependia do Node que viesse na imagem — e usava npm install, que pode resolver versões diferentes do lockfile. Agora usa setup-node com cache e npm ci.

3. Reduzir a permissão do token

permissions: contents: write existia para o passo de auto-commit. Sem ele, contents: read basta.

4. Deixar main em conformidade

Um gate estrito sobre uma base que não passa deixa o repositório vermelho no primeiro merge. Os dois primeiros commits deste PR aplicam os formatadores:

Commit	Conteúdo
style: apply pint to app/	2 arquivos, saída do vendor/bin/pint
style: apply prettier to resources/	15 arquivos, saída do npm run format

Ambos são mecânicos e revisáveis por commit. O churn do Prettier é menor do que a contagem de arquivos sugere: 97 inserções, 91 remoções, quase tudo quebra de linha.

O erro do eslint foi resolvido dentro do commit do Prettier: o plugin prettier-plugin-organize-imports, que já estava configurado, removeu sozinho o getPortugueseMonth não utilizado em TagPosts.vue.

Como validar

Rodando exatamente os quatro comandos do workflow:

vendor/bin/pint --test
npm run format:check
npm run lint:check
npm run type-check

Os quatro passam nesta branch. Verificado também que reprovam de verdade: contra main, os três primeiros falham.

Impacto

• Comportamento da aplicação: nenhum. Só formatação e configuração de CI.
• Fluxo de trabalho: PRs com estilo, lint ou tipos fora do padrão passam a ser reprovados. npm run format e vendor/bin/pint continuam disponíveis para corrigir localmente.
• Diff: 19 arquivos, dos quais 17 são formatação mecânica.
• Rollback: reverter o commit de CI mantém a formatação; reverter os três desfaz tudo.

Ordem de merge sugerida

Vale mesclar este PR cedo na série. Enquanto main tiver as violações atuais, os demais PRs aparecem com CI vermelho por um motivo que não é deles.

Fora de escopo

• O workflow tests não foi alterado. Ele falha hoje, mas por falta das tabelas wp_* no ambiente de teste, o que é resolvido no PR de infraestrutura de testes. Misturar as duas coisas aqui tornaria este PR mais difícil de revisar.
• Nenhuma regra de lint foi adicionada ou afrouxada. As configurações de pint, eslint e prettier continuam exatamente como estavam; este PR só passa a executá-las de um jeito que importa.