refactor: prefixo no nome das branches — feature/ e chore/

[ronifabio]

O que este PR faz e por quê

O template criava branches sem prefixo — 27-reserva-de-carona para história e
setup-projeto para o scaffold. Funciona, mas não é o que o aluno encontra no mercado:
o CLI do git flow e praticamente todo material da área usam feature/, e uma listagem
de branches sem prefixo não diz o tipo de nada.

Fui conferir antes de mudar, porque a intuição podia estar errada. No modelo original do
Gitflow, branches de feature podem se chamar qualquer coisa — só release-* e hotfix-*
têm nome obrigatório. Ou seja: o feature/ é convenção da ferramenta, não do modelo.
Adotei mesmo assim, porque é o que se reconhece, e mantendo o número da Issue no nome,
que é o que amarra branch, Issue, Pull Request e pasta da spec.

Duas coisas ficam escritas para o agente não errar na primeira tentativa:

A pasta da spec não leva prefixo — continua specs/<numero>-<slug>/. O prefixo é da
branch, não do caminho no disco. Sem essa frase o agente cria specs/feature/27-.../ e
quebra a contagem de rodadas de revisão, que é a listagem desse diretório.

E chore/ para manutenção — bug, tarefa técnica, setup —, que casa com o vocabulário
de Conventional Commits que as mensagens de commit já usam. Um prefixo por família, os
dois lugares falando a mesma língua.

O CONTRIBUTING ganha também a nota de que release/* e hotfix/* existem no Gitflow e
não são usados aqui: não há trem de release nem correção de emergência separada, a
publicação é o próprio PR de develop para main. O aluno vai encontrar esses nomes em
tutorial e precisa saber que não esqueceu nada.

Apontamentos da revisão

Não se aplica — PR de manutenção, sem spec.md.