docs(B31): marca adiado do Context como resolvido pela 2ª rodada de /simplify

docs/plans/dobradinhas-lista-liderancas.md

@@ -161,7 +161,7 @@ Três revisores paralelos (qualidade, performance, reuso) sobre o diff completo.
 Adiados (achados reais, mas fora do apetite deste item — ver também o "2º call site" acima):
 
 - Unificar `nextStateDeputyIdsAfterMembership`/`nextAdvisorIdsAfterMembership` num helper genérico parametrizado — casa com a extração adiada para o 3º call site (B34/B36/B37), não antes.
-- `StateDeputyOptionsProvider` como Context vs. props diretas: um revisor sugeriu trocar por uma columns factory; outro validou o Context como decisão correta (só um consumidor hoje, mesmo padrão de `MunicipalityEstimateScenarioProvider`). Mantido como está — não há um 2º catálogo consumindo o Context ainda para justificar a escolha de forma ou outra.
+- ~~`StateDeputyOptionsProvider` como Context vs. props diretas~~ — **revertido na 2ª rodada** (ver abaixo): a evidência que faltava nesta 1ª rodada (o precedente `municipalityListColumns`) apareceu na 2ª.
 - Query duplicada de `stateDeputy` na página da lista (catálogo completo para o Popover + subconjunto por IDs em `toLeadershipRows`) — `toLeadershipRows` é compartilhado com rotas que não carregam o catálogo, então não pode simplesmente consumi-lo; ficaria como uma otimização condicional só para esta rota.
 
 Gate verde novamente após os ajustes (tsc, lint, format:check, unit 526/526, int 406/406 incl. os 6 do B31, build); Aikido 0 achados nos 4 arquivos tocados pelo `/simplify`.
@@ -172,7 +172,7 @@ Mesmos três revisores paralelos sobre o diff (já rebaseado em `origin/main`).
 
 - **`StateDeputyOptionsProvider` revertido para prop direta.** A primeira rodada tinha decidido manter o Context; esta rodada trouxe a evidência concreta que faltava — `MunicipalityList.tsx` já resolve exatamente o mesmo problema ("colunas estáticas + uma coluna que precisa de opções por request") com uma **columns factory** (`municipalityListColumns(props)`, chamada dentro do componente, fechando sobre `advisorOptions`), sem Context. Adotar esse precedente em vez de divergir dele: `leadershipColumns` virou `leadershipColumns(stateDeputyOptions)`, `LeadershipStateDeputiesCell` recebe `options` como prop comum, e `StateDeputyOptionsProvider.tsx` foi deletado. Zero comportamento mudado, um arquivo e uma camada de Context a menos.
 - **`revalidatePath` mais largo que o necessário.** `revalidateLeadershipStateDeputyPaths` chamava `revalidatePath('/campanha/liderancas/[id]', 'page')` — a forma de padrão dinâmico, que invalida a entrada de cache de **toda** ficha de liderança a cada toggle, não só a tocada — mesmo com o `leadershipId` já em escopo. Contrasta com o precedente já estabelecido (`revalidateAdvisorPaths`/`revalidateMunicipalityListPaths`), que sempre usa o id/slug concreto quando ele é conhecido. Corrigido para `revalidatePath(`/campanha/liderancas/${leadershipId}`, 'page')`.
-- **Non-null assertion evitável.** `optionById.get(stateDeputyId)!` dentro do `setCurrent` updater dependia de uma guarda feita *fora* do updater (`if (assigned && !optionById.has(...)) return`) — correto hoje, mas as duas partes podiam se separar numa edição futura sem o TypeScript avisar. Movida a checagem para dentro do próprio updater (`if (!option) return previous`), sem asserção.
+- **Non-null assertion evitável.** `optionById.get(stateDeputyId)!` dentro do `setCurrent` updater dependia de uma guarda feita _fora_ do updater (`if (assigned && !optionById.has(...)) return`) — correto hoje, mas as duas partes podiam se separar numa edição futura sem o TypeScript avisar. Movida a checagem para dentro do próprio updater (`if (!option) return previous`), sem asserção.
 
 Adiados (achados reais desta rodada, registrados para quem tocar este código de novo):