feat: RBAC for RTC write modes (Gerenciador ADMIN only, denials audited), central backpressure for heavy jobs (HEAVY_JOB_CONCURRENCY_LIMIT), concurrency simulation evidence

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/rtc_auto_apply.md

@@ -21,6 +21,12 @@ Sequência por produto (uma transação curta): reler tudo → recalcular a deci
 ## Reautorização imediata antes da escrita (1.2.1)
 O modo entregue no job pode envelhecer (operador desativa durante um lote). Antes de **cada** UPDATE o Agent relê a autorização atual no Hub (`GET /v1/agents/me/authorizations`, autenticado pelo token do próprio Agent; devolve só modo, aprovados e reversões da sua instalação; cache de 3 s). Se o modo mudou, se o produto perdeu a aprovação ou se o Hub não puder ser consultado, o produto é interrompido **sem escrever** (`AUTHORIZATION_CHANGED` / `AUTHORIZATION_UNVERIFIABLE`). Autorização não confirmada não é autorização.
 
+## Quem pode mudar o que (RBAC, 1.2.1)
+A identidade vem do SSO do GTI Gerenciador (`perfil`). **ADMIN** (e contas LOCAL de emergência) pode: `APPROVAL_REQUIRED`/`ENABLED`, aprovar/rejeitar, aplicar aprovados e reverter. Um colaborador **PADRAO** só vê a página e alterna `DISABLED`/`DRY_RUN` (somente leitura); tentativas restritas devolvem 403 e ficam auditadas (`RTC_DENIED`). Sair de um modo de escrita também é restrito a ADMIN. Toda mudança de modo, aprovação e reversão grava o operador e o perfil no evento de auditoria.
+
+## Backpressure de jobs pesados (1.2.1)
+`HEAVY_JOB_CONCURRENCY_LIMIT` (padrão 3; `<=0` desliga): no máximo N jobs `INITIAL_SYNC`/`REPROCESS_ALL` rodam ao mesmo tempo em **todos** os Agents; os demais ficam `PENDING` (fila) e o Agent segue com heartbeat e polling. Um job leve nunca fica preso atrás de um pesado. Job RUNNING há mais de 1 h não ocupa vaga. Medição (8 Agents × 1.042 produtos, Hub de desenvolvimento): sem limite 51,9 produtos/s, CPU pico 149%, cada Agent até 160 s; com limite 3: 66,7 produtos/s, CPU pico 116%, cada Agent até 45 s (espera máx. 88 s), 0 falhas.
+
 ## Preview e aprovação
 O Agent envia os candidatos (até 5.000 por job; `preview_truncated` sinaliza excesso) → tabela `rtc_candidates` (PENDING/APPROVED/REJECTED/APPLIED/STALE). O painel pagina no servidor (50/página), filtra por status, aprova/rejeita selecionados ou todos os pendentes e dispara "Aplicar aprovados agora". Uma proposta que muda invalida a aprovação anterior; produto que deixa de ser elegível numa avaliação completa vira `STALE`.
 

docs/runs/final_corpus/concurrency_sim.json

@@ -0,0 +1,28 @@
+{
+ "agents": 8,
+ "products_per_agent": 1042,
+ "runs": [
+  {
+   "limit": "none",
+   "wall_s": 160.6,
+   "products_per_s": 51.9,
+   "failures": 0,
+   "max_run_s": 160.6,
+   "max_queue_wait_s": 0.0,
+   "hub_cpu_peak_pct": 149.18,
+   "hub_cpu_avg_pct": 130.0,
+   "hub_mem_peak_mib": 89.19
+  },
+  {
+   "limit": 3,
+   "wall_s": 124.9,
+   "products_per_s": 66.7,
+   "failures": 0,
+   "max_run_s": 45.5,
+   "max_queue_wait_s": 88.4,
+   "hub_cpu_peak_pct": 115.81,
+   "hub_cpu_avg_pct": 71.3,
+   "hub_mem_peak_mib": 79.25
+  }
+ ]
+}