fix: admin: exercícios: ordenamento deve ser para toda a lista (não somente para a página)

# Contexto
A listagem de exercícios no CMS precisa respeitar a ordenação da lista inteira, e não apenas a ordenação dos itens já carregados na página atual. Hoje a tela de admin consome a API paginada, mas a interface permite ordenação nas colunas sem coordenar esse critério com a API. No backend, a consulta de exercícios já aplica ordenação por [sequence](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/8b640eef5a/resources/app/out/vs/code/electron-browser/workbench/workbench.html), mas o fluxo ainda precisa ser validado para garantir que a ordenação global continue correta mesmo com paginação.

## Critérios de aceite

- A listagem de exercícios deve seguir uma ordem global consistente em todas as páginas.
- A ordenação não pode ser aplicada apenas aos itens da página atual.
- A navegação entre páginas deve manter a sequência correta dos registros.
- A tabela do CMS deve exibir os exercícios na mesma ordem definida pela API.
- A experiência de ordenação no admin não deve quebrar o carregamento da lista nem a paginação.
- Se houver ordenação por coluna no frontend, ela deve refletir o comportamento esperado da API e não sobrescrever a ordem global da lista.

## Notas técnicas
Esse card é mais de integração front + API, mas o ponto principal está no comportamento da listagem no admin. O front monta a tabela em src/components/PageElements/cms/render-exercises.tsx e a tabela base em src/components/UI/cms/table-cms.tsx marca as colunas como ordenáveis, mas não envia critério de sort para a API. No backend, src/services/exercise/ExerciseService.ts já usa [orderBy: { sequence: 'asc' }](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/8b640eef5a/resources/app/out/vs/code/electron-browser/workbench/workbench.html) antes da paginação, então a correção provavelmente está em alinhar o comportamento do front com essa ordenação, ou em ajustar a API caso o sort deva ser dinâmico.

# Obs
“O trabalho é flexível. Durante a execução, a dupla pode identificar melhorias nas especificações, ajustes de rota ou uma forma melhor de resolver o problema. Isso é esperado. Se for necessário mexer no frontend, no backend ou nos dois, a decisão pode mudar conforme a análise técnica. Nesses casos, devem ser criadas branches e PRs separados quando fizer sentido, e os links devem ser registrados no próprio card. Também é importante descrever no card o que foi feito, quais decisões foram tomadas e o motivo de eventuais mudanças de abordagem, garantindo clareza, rastreabilidade e autonomia da dupla.”