feat: scope Editor app administration by group (#990 slice 1)

[milkway]

Fatia 1 de 5 da #990, a maior delas. Implementada por agente codex exec (gpt-5.6-sol, high); diff e gate revisados e reexecutados por mim, com uma correção minha no caminho do cache (e92c2ad).

O que muda

O escopo por grupo do Editor passa a valer nas Aplicações: specs.rs, spec_form.rs e as réplicas do dashboard.rs. Apps abertos seguem Editor-globais, como você decidiu. Admin e sessão de token seguem irrestritos. images.rs ficou de fora de propósito — mídia é biblioteca compartilhada, não tem dono.

Rota fora do escopo responde 404, não 403, para não vazar a existência do app.

O buraco que a revisão da fatia 0 tinha antecipado

specs.rs::index não itera Spec: faz o SELECT enxuto do #588 e depois enriquece as linhas com metadados do catálogo efetivo. Um id ausente desse mapa deixa access_groups vazio, e o app restrito pareceria aberto — que, sendo app aberto Editor-global, seria bypass silencioso com o teste feliz verde.

Tratado nos dois caminhos da listagem (linhas do banco e linhas "config-defined" do YAML): sem resolver no catálogo efetivo, o Editor escopado não vê. Nas mutações a autorização usa db::specs::fetch_one, a fonte autoritativa do spec no banco.

Vazamento que o agente achou, e a correção que eu fiz por cima

Achado dele: a chave do cache do snapshot do dashboard era só o locale — reaproveitá-la para Editor escopado serviria as linhas de um time para outro. Vazamento entre times via cache.

A correção dele foi desligar o cache para escopados. Correta, mas joga fora a razão de o cache existir: o #291 existe porque construir um snapshot lê o registry, consulta o catálogo efetivo e monta as linhas, e cada aba faz polling no seu próprio intervalo de 5 s. Sem cache, toda aba de Editor reconstrói a cada tick — exatamente a pressão de múltiplas abas que travou a admin atrás de front HTTP/1.1 no #1039/#1040.

Minha correção (e92c2ad): chave (locale, escopo). Admin/break-glass compartilham uma entrada, dois Editores do mesmo conjunto de grupos compartilham a deles, e ninguém lê a de outro escopo. A chave de escopo ordena e deduplica (["a","b"] e ["b","a"] são o mesmo escopo e não devem partir o cache) e junta pelo separador de unidade, para um grupo chamado a,b não forjar a chave de ["a","b"]. Teste prende os três casos.

Enumeração de rotas: conferida, não aceita de boa-fé

O teste scoped_editor_gets_404_on_every_foreign_app_or_replica_id_route lista 7 rotas de app e 4 de réplica. Comparei com o roteador: são exatamente 11 as rotas com id nesses três arquivos (edit, duplicate, POST /admin/specs/{id}, delete, repull, state/toggle, featured/toggle, logs, logs/stream, stop, restart). Cobertura exaustiva.

Outras verificações da revisão

• Criação: app restrito tem de nascer com grupo do Editor (may_assign_groups + may_touch_spec sobre o candidato); app aberto passa por is_open.
• Edição: valida o pedido, faz o merge preservando grupo de fora do escopo, e revalida o spec resultante — o Editor não consegue se expulsar do próprio app.
• Dashboard: o handler constrói o escopo a partir do AdminSession para preservar o redirect do Viewer para / (Viewer role: drop admin-panel access — only change-password + logout #857) em vez de trocá-lo por 403.
• Réplica: scoped_replica_spec resolve o spec dono antes de qualquer acesso ao backend e falha fechado quando o metadado não resolve.
• Alteração no primitivo compartilhado (scope.rs, +10 linhas): só from_editor virando pub(crate) e um helper actor(). Nenhum predicado foi afrouxado.

Gate reexecutado por mim: cargo test limpo, clippy --all-targets -- -D warnings sem warning, i18n-check OK.

🤖 Generated with Claude Code