fix(ir): corrigir um trecho gasta orçamento de reconto

[henokteixeira]

Fecha ENG-685. Independente da pilha 676/679/680 — sai da main e vai para a main.

Summary

MAX_RETELLS = 3 existe para que a equipe nunca fique presa recontando: quando o orçamento
acaba, a sala para e pede uma pessoa. Ele era cobrado num lugar só — POST /back-translation/chunks, e apenas com retelling=true.

A correção de um trecho não passa por ali. Passa por POST /segments/{id}/replace, e essa
rota não tocava no orçamento. O único limite que a sala tem contra prender uma equipe recontando
não cobria o caminho pelo qual a equipe de fato corrige — e numa sala onde ninguém lê e o
facilitador é uma voz, uma equipe presa nesse ciclo não tem como pedir ajuda.

Esta fatia torna as duas rotas simétricas: somar, gravar o estado, e pedir uma pessoa quando
estourar. Escolhida a saída (a) da issue; a (b) foi descartada.

A decisão de desenho: qual das duas formas de substituir gasta

Substituir tem duas formas, e só a que traz uma explicação nova gasta — /replace com
arquivo. A chamada sem arquivo, que regrava o áudio nativo, não gasta.

Não é preferência: é o que o próprio código já dizia. O docstring de capture_segment:

"the product has two corrections and not three: redoing only the explanation, which leaves
the native audio exactly where it is, and re-recording the native, which always means the
explanation is redone after it."

Regravar o nativo nunca é uma correção completa — é sempre seguido de uma segunda chamada, com
arquivo, que traz a explicação. São dois passos de uma tentativa. Contar os dois cobraria
duas unidades por uma correção, e a equipe chegaria ao fim do orçamento em uma volta e meia,
punindo justamente a correção mais completa.

E alinha com o vizinho: em /chunks quem marca o gasto é retelling, documentado como "telling
one stretch back a second time after a finding". O orçamento é sobre contar de novo, não
sobre gravar de novo. Com esta escolha, as duas formas de corrigir custam exatamente 1.

Duas consequências que decorrem dela:

• Requisição inválida não gasta. Fatia movida com áudio junto, ou payload acima do limite,
  são recusados antes de qualquer gasto — a rota já argumenta que "what is not stored first is
  a request that cannot succeed". Requisição malformada não é tentativa da equipe.
• Transcrição vazia gasta, pelo argumento que a rota irmã já carrega por escrito: se só o
  sucesso contasse, uma queda do transcritor deixaria a equipe corrigindo para sempre e a rota
  para uma pessoa ficaria inalcançável exatamente quando a sala está quebrada.

⚠️ Isto ainda não muda o que a equipe vê no caminho de /replace

SegmentsResponse ganhou needs_person, como BackTranslationChunkResponse já tinha. O app
não lê esse campo — TellingAgain.fromJson lê apenas segments e captured — então por
enquanto o servidor avisa e o cliente descarta o aviso em silêncio. O lado do app está sendo
feito em paralelo; até ele chegar, o comportamento visível nesta rota não muda.

O aviso não se perde inteiramente, e isso importa para avaliar o risco. mark_needs_person
grava o estado na própria sessão (status = needs_person), que GET /sessions/{id} serve. A
parada é persistente, não uma menção única numa resposta: qualquer leitura seguinte do estado a
encontra. O caso test_the_room_that_stopped_says_so_in_its_own_state guarda exatamente isso.

Test plan

Sete casos em tests/test_internalization_room_segment_verbs.py, todos pela rota, perguntando o
que o orçamento marcou e o que a sala passou a oferecer — nenhum lê estado interno.

Caso	O que guarda
test_correcting_a_stretch_spends_retell_budget	Corrigir gasta
test_the_budget_runs_out_and_the_room_offers_a_person	O estouro chama uma pessoa, e a resposta daquela correção não se perde
test_the_budget_is_spent_on_the_attempt_not_on_the_result	Gasto na tentativa, não no resultado
test_telling_a_new_stretch_never_spends_retell_budget	O controle mais importante
test_the_telling_back_route_still_counts_the_way_it_counted	A rota vizinha não muda
test_dividing_a_stretch_is_not_correcting_and_spends_nothing	Dividir não é recontar
test_the_room_that_stopped_says_so_in_its_own_state	A parada sobrevive à resposta que a carregou

RED antes da implementação: 1, 2 e 3 vermelhos (assert 0 == (0 + 1), assert 0 >= 3,
assert 0 == (0 + 1) — o orçamento parado em zero); 4 e 5 verdes. Os dois últimos casos foram
acrescentados por mim para os casos de borda do plano.

Casos de borda

• Dividir um trecho não gasta — é a equipe ouvindo duas ideias onde contou uma, escrevendo
  duas linhas contra um áudio que já estava lá. Nenhum áudio cruza a rede e nada é recontado;
  cobrar seria gastar o orçamento da equipe num ato de leitura. Com caso próprio.
• Sessão retomada — o número vive no estado guardado da sessão, e o caso do estouro já o
  demonstra: são três requisições HTTP separadas e o número acumula entre elas.
• Estouro exatamente na última correção permitida — a equipe recebe os trechos daquela
  correção e a marca de parada. Perder a resposta seria pior que o problema; asseverado no
  caso do estouro.

Números

Baseline medida na main atual antes de tocar em nada: 2344 passed, 5 skipped, 1 xfailed.
Depois: 2351 passed, 5 skipped, 1 xfailed — a baseline mais exatamente os sete novos.
ruff check, ruff format e mypy app limpos (596 arquivos).

[linear-code]

ENG-685