Persistent practice/training mode outside live contests

Summary

microHelium is contest-only: every Problem row is scoped to a Contest (app/Http/Controllers/ProblemController.php always queries $contest->problems()), and every Run requires a contest_id. There's no way for a team to practice on past problems, or for anyone to browse/solve problems outside an active event.

Inspiration

cd-moj/cdmoj has a persistent "Treino Livre" (free training) mode: a public problem archive browsable anytime, with real submissions/verdicts, personal solve history, and per-problem statistics (attempts, solve rate, a smoothed "harder than X% of the archive" percentile).

Why this matters

Teams want to practice between events using real problems and a real judge, not just read statements.
A problem archive with attempt/solve-rate stats also makes ProblemBank (app/Models/ProblemBank.php) more useful for admins picking problems for a new contest (issue: which bank problems are actually well-calibrated?).

Suggested scope (phased, since a full decoupling of Run/Score from contest_id is a large schema change)

Phase 1 (small-medium): a permanent, non-expiring "Practice" pseudo-contest per problem-bank entry (or one shared practice contest), reusing the existing Contest/Problem/Run/Score/AutoJudgeService pipeline as-is -- no core schema changes. A team can submit against any ProblemBank problem that's been "published" to practice.
Phase 2: per-problem stats (attempts, solve rate) computed from Score/Run history, shown on the problem list.
Phase 3 (stretch): true decoupling of practice submissions from any contest_id, with personal history/profile pages.

This is the single largest structural gap identified when comparing against other modern judge platforms -- worth scoping carefully before starting, given the size.

Vou assumir o frontend e a especificação de integração desta issue, conforme solicitado pelo mantenedor, na worktree isolada feat/issue-frontends-specs, baseada em master após o PR #35.

Frontend de Treino Livre: biblioteca pesquisável, enunciado/envio e histórico pessoal, com estados de carregamento, vazio e falha. Spec da fase 1 usando um concurso de prática compartilhado e isolado dos eventos; publicação explícita do banco, contratos de submissão e estatísticas sem expor dados privados. Desacoplamento de contest_id fica para fase posterior.

Antes da implementação, registro a divisão: minhas mudanças serão interfaces, rotas GET de apresentação, testes de frontend e specs em docs/specs/. Models, migrations, jobs, regras de domínio e endpoints de dados/mutação ficam com o time de backend. As interfaces só habilitarão ações quando o contrato real estiver disponível; haverá estado de indisponibilidade, sem confirmação fictícia de sucesso.

Critérios de aceite do frontend: navegação por teclado, labels visíveis, feedback de processamento/erro, cores sem significado exclusivo, layout responsivo e testes dos fluxos principais. Vou vincular o PR e os contratos finais aqui; esta entrega não encerra a implementação de backend da issue.

Entrega publicada no PR #70: #70

Spec desta issue · Índice dos contratos

Frontend implementado com estados de carregamento, vazio, erro e permissões. Os endpoints de dados/mutação ainda dependem da implementação do contrato pelo backend; nenhuma confirmação de sucesso é simulada.

Validação da branch: 604 testes PHP (3248 assertions), 26 testes de frontend e build aprovados. Fluxos Vue foram testados com contratos de teste; integração funcional exige endpoints reais. Revisão visual de biblioteca/enunciado feita no navegador, incluindo 375 px; telas administrativas tiveram revisão de código/componentes, com conferência visual limitada por bloqueio de outra extensão no Chrome.

As responsabilidades e critérios de aceite estão na spec. Este PR não encerra o trabalho pendente do backend.

feat(#46): problem-bank ownership (organizations/tags) + real bank-go…