fix: release QA hardening across processing, media, security, and CI gates (#649)

A release-readiness QA pass over the whole product. The commits split into
defects a user would hit and gates that were reporting green while measuring
nothing.

## Fixes that change behaviour

Rate limiting was bypassable on every install: TRUST_PROXY defaulted to true, so
request.ip came from a client-set header and a forged X-Forwarded-For got past
the login limiter. The default is now a private-network trust list.

A transient Postgres outage stranded in-flight jobs, leaving finished output on
disk with no row pointing at it. A reconciler now resolves those rows and adopts
the bytes rather than dropping the work.

A Redis connection that moved to a new address wedged every read-blocked
consumer, so completions stopped signalling while health still answered 200.
Socket timeouts plus subscriber pings recover it.

Installing more than one AI bundle left the shared venv multi-versioned and
silently broke three tools. The installer now reconciles distributions to one
version each.

Converting an image to JXL at quality 1 through 4 returned a 500, because
libjxl 0.7 rejects the distance those values compute. The quality is floored at
what the encoder honours. A missing ffmpeg was also reported to the user as a
corrupt upload; it now says the engine is unavailable.

RAW uploads reached an unpatched LibRaw on arm64, so it is built from source at
0.22.2, and the release scan was split so it can fail on an unfixed critical
instead of hiding it behind ignore-unfixed.

## Gates that could not fail

Two mutation lanes ran zero mutants because Stryker crawled the gitignored docs
build; coverage discarded its whole report on any failing test; the lint gate
skipped root tests, scripts, and two workspaces; and several generated matrices
counted a host missing ffmpeg as a passing tool. Each now measures what it
claims.

Full evidence and the outstanding release items are tracked locally and are not
part of this branch.

apps/docs/pt-BR/guide/users-roles.md

@@ -1,8 +1,9 @@
 ---
 description: "Gerencie usuários, papéis integrados e personalizados, permissões, chaves de API, times, sessões e o log de auditoria no SnapOtter."
-i18n_source_hash: 5e28af686c96
+i18n_source_hash: bea8955f3aff
 i18n_provenance: human
-i18n_output_hash: 520ee01a5650
+i18n_output_hash: 4146f4acdfc0
+i18n_hash_version: 2
 ---
 
 # Usuários, Papéis e Permissões {#users-roles-permissions}
@@ -82,12 +83,12 @@ Todas as 17 permissões. Controle total sobre a instância.
 | `pipelines:all` | Ver e gerenciar os pipelines de todos os usuários |
 | `settings:read` | Ver as configurações da instância |
 | `settings:write` | Modificar as configurações da instância |
-| `users:manage` | Criar, atualizar e excluir contas de usuário |
+| `users:manage` | Criar e gerenciar contas de usuário dentro dos limites de autoridade do ator |
 | `teams:manage` | Criar, atualizar e excluir times |
 | `features:manage` | Instalar e gerenciar bundles de recursos de IA |
 | `system:health` | Acessar os endpoints de health e readiness |
 | `audit:read` | Ver o log de auditoria e listar papéis |
-| `compliance:manage` | Gerenciar o ciclo de vida de GDPR e recursos de conformidade |
+| `compliance:manage` | Gerenciar o ciclo de vida e os recursos de conformidade do GDPR; operações destrutivas do usuário permanecem limitadas pela autoridade |
 | `webhooks:manage` | Configurar webhooks de saída |
 | `security:manage` | Gerenciar configurações de segurança (lista de IPs permitidos, imposição de SSO) |
 
@@ -110,15 +111,17 @@ curl -X POST http://localhost:1349/api/v1/roles \
 
 Os nomes de papéis devem ter de 2 a 30 caracteres, alfanuméricos em minúsculas, com hifens e underscores.
 
-### Permissões reservadas ao admin {#admin-reserved-permissions}
+### Limites de administração delegada {#delegated-administration-boundaries}
 
-Três permissões são reservadas aos papéis integrados e não podem ser atribuídas a papéis personalizados:
+Todas as 17 permissões podem ser delegadas por meio de funções personalizadas, mas uma permissão administrativa não torna essa função equivalente à função `admin` integrada. Mutações de usuário autorizadas por `users:manage`, operações destrutivas autorizadas por `compliance:manage` e gerenciamento de função personalizada autorizada por `security:manage` são limitadas pela autoridade atual do ator:
 
-- `compliance:manage`
-- `webhooks:manage`
-- `security:manage`
+- As funções integradas seguem `admin` > `editor` > `user`; as funções personalizadas estão abaixo das funções integradas.
+- As permissões do alvo devem estar contidas nas permissões **efetivas** do ator. Uma chave de API com escopo definido, portanto, não pode exercer permissões omitidas de seu escopo.
+- O acesso à ferramenta de uma função alvo deve ser contido pelo acesso à ferramenta do próprio ator.
+- Uma conta desativada é verificada em relação à sua função original quando essa função é registrada como `disabled:<original-role>`.
+- A exclusão de uma função personalizada também requer autoridade para atribuir o substituto `user` integrado; membros desabilitados permanecem desabilitados como `disabled:user`.
 
-A API de papéis rejeita qualquer requisição que inclua essas permissões. Somente o papel integrado `admin` tem acesso a elas.
+As credenciais e a configuração globais são mais rigorosas: a emissão ou revogação do token SCIM e a importação da configuração da instância exigem a função `admin` integrada com autoridade administrativa completa e efetiva.
 
 ### Permissões no nível de ferramenta {#tool-level-permissions}