docs(aula-10): explicar SERVE_DIRECT e segurança de signed URLs

aula-10/README.md

@@ -375,7 +375,37 @@ gitea:
 
 4. `helm upgrade` pra aplicar
 
-Com `SERVE_DIRECT: true`, o Gitea redireciona `docker pull` direto pro S3 — menos carga na CPU, downloads mais rápidos.
+### SERVE_DIRECT: como funciona (e por que é seguro)
+
+Com `SERVE_DIRECT: true`, o Gitea **não** faz proxy dos downloads. Em vez disso, gera **URLs pré-assinadas** com expiração:
+
+```
+docker pull gitea.kube.quest/org/app-privada:v1
+  │
+  ├─ 1. Client autentica no Gitea (token/password)
+  │
+  ├─ 2. Gitea verifica permissão (repo privado? user tem acesso?)
+  │     → Se não tem acesso: 403 Forbidden. Para aqui.
+  │
+  ├─ 3. Gitea gera URL S3 pré-assinada (expira em ~10 minutos)
+  │     https://s3.example.com/gitea/packages/sha256:abc...
+  │       ?X-Amz-Signature=xxx&X-Amz-Expires=600
+  │
+  └─ 4. Client baixa direto do S3 via URL assinada
+         → URL expira, não pode ser reutilizada
+         → Repo privado permanece privado
+```
+
+Sem `SERVE_DIRECT` (default):
+```
+Client → Gitea (proxy) → S3 → Gitea (proxy) → Client
+         ^^^^^^^^^^^^         ^^^^^^^^^^^^
+         CPU + RAM + bandwidth passam pelo Gitea
+```
+
+**Repos privados continuam privados** — a URL assinada só é gerada após autenticação e verificação de permissão. É o mesmo mecanismo usado por AWS S3, GitHub Packages e Google Cloud Storage.
+
+Único cenário onde **não** usar `SERVE_DIRECT`: se o bucket S3 está em rede privada e os clients não têm acesso direto à rede do S3.
 
 ### Ou só pra packages (container images)