docs(platform-tools): regista a tentativa revertida de apertar permissões

config/cache/ e assets/img/seo/ passaram a volumes próprios
(/srv/data/fitme.andmore.pt/{cache,seo}), mas o checkout continua
664/2775: o deploy-on-push corre como www-data dentro do pedido do
webhook, não como deploy, e 644/2755 partiu a primeira push a seguir
("Permission denied" a criar um ficheiro novo). Documentado para a
próxima vez que alguém for tentar isto outra vez.

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

PLATFORM_TOOLS.md

@@ -43,3 +43,14 @@ for that endpoint already resolves to the same
 `CLAUDE_GITEA/.auto-update-secrets` on Andre's machine), and
 `system_settings.auto_update_enabled = '1'`. Toggle it off from Sistema →
 Atualizar plataforma if a push needs to land without auto-deploying.
+
+**Why the checkout stays group-writable (664/2775, `deploy:www-data`):** the
+webhook's `git pull` runs *inside the PHP request*, as `www-data`, not as
+`deploy`. Tried tightening to 644/2755 on 2026-09-25 (audit 2.6) and the very
+next push failed with "Permission denied" creating a new file — reverted
+within minutes. `config/cache/` and `assets/img/seo/` (the app's only two
+runtime-write targets inside the checkout besides `uploads/`/`logs/`/
+`backups/`, which already had their own volumes) got their own bind mounts
+from `/srv/data/fitme.andmore.pt/` in `compose.yml`, same pattern fotografia
+uses — but the checkout itself can't go read-only for `www-data` without
+giving up deploy-on-push.