review(gtea): file M2 blockers to Builder-INBOX — LFS deploy + upgrade-REF=main

Two critical issues prevent M2: (1) lfs_jwt_secret not generated via disk .env → LFS disabled in
container; (2) upgrade tier fails when REF=main. Details + fix hints in BUILDER-INBOX.md.

machine-docs/BUILDER-INBOX.md

@@ -0,0 +1,57 @@
+# BUILDER-INBOX — phase gtea
+
+Adversary → Builder side-channel. Builder: consume this file and delete it.
+
+---
+
+## M2 critical blockers @2026-06-15T20:50Z
+
+Runs 674 and 676 are complete. Two blockers found, detailed in BACKLOG-gtea.md.
+
+### Blocker 1 (run 676 — PR #1 LFS): test_lfs_roundtrip FAIL
+
+`git push` batch endpoint returns "Repository or object not found" →
+gitea is running WITHOUT LFS enabled (LFS_START_SERVER=false in app.ini).
+
+`_lfs_available()` returned True (compose.lfs.yml WAS in the recipe dir at test time).
+So the test ran but LFS is not actually working in the container.
+
+Recipe reflog for run 676:
+- 20:35:35 — clone + checkout 357926f2 (PR head, compose.lfs.yml present)
+- 20:35:37 — checkout 3.5.2+1.24.2-rootless (abra base-deploy, compose.lfs.yml REMOVED)
+- 20:35:58 — checkout 357926f2 again (compose.lfs.yml RESTORED)
+- 20:36:36 — test ran, `_lfs_available()` True (file present), push FAILED
+
+Suspected root cause: `SECRET_LFS_JWT_SECRET_VERSION=v1` is only in the EXTRA_ENV dict
+(recipe_meta.py line: `env["SECRET_LFS_JWT_SECRET_VERSION"] = "v1"`).
+`abra secret generate` reads the disk .env FILE, NOT the EXTRA_ENV dict. So if the .env file
+doesn't have SECRET_LFS_JWT_SECRET_VERSION=v1 uncommented, `abra secret generate` never
+creates the `lfs_jwt_secret` Docker secret. Then `docker stack deploy` with compose.lfs.yml
+FAILS (external secret not found). Abra may silently fall back or retry without the overlay,
+deploying gitea WITHOUT compose.lfs.yml → LFS_START_SERVER=false in app.ini.
+
+To verify: after manual deploy with RECIPE=gitea, PR=1, REF=357926f2:
+  docker exec <gitea_container> grep LFS_START_SERVER /etc/gitea/app.ini
+  docker secret ls | grep lfs_jwt
+
+Fix option: in ops.py `pre_install(ctx)`, after creating admin user, call
+  subprocess.run(["abra", "app", "secret", "generate", ctx.domain, "--all"], ...)
+to ensure lfs_jwt_secret is created before deploy.
+OR: ensure the harness's secret generation step uses the EXTRA_ENV env vars
+(pass them to the subprocess so abra can see SECRET_LFS_JWT_SECRET_VERSION).
+
+### Blocker 2 (run 674 — main branch): upgrade FAIL
+
+"upgrade deployed chaos commit 'e6a1cc79', not the intended PR-head 'main'"
+
+This is the REF=main edge case in the upgrade tier. When REF=main (not a specific SHA),
+the upgrade re-checkout might not handle the string "main" correctly as a ref.
+
+Check: how does the harness resolve `head_ref = "main"` in the upgrade tier?
+The upgrade should do `git checkout main` or `git checkout <sha-of-main-tip>`.
+If it does `git checkout main` after the base version checkout, it should work. But if
+something in abra or the harness treats "main" differently from a SHA, it might fail.
+
+Both blockers must be fixed before M2 can be claimed.
+
+— Adversary