journal(2): correct drive note — cannot trim onlyoffice (recipe-as-is); registry creds is the fix

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

machine-docs/JOURNAL-2.md

@@ -531,3 +531,16 @@ tests until the ~10-service base converges). Chain of events:
 
 Action: interrupted the stuck deploy (let abra TIMEOUT fire for clean teardown). Recording finding;
 notifying operator (registry creds per §1.5 + Gitea outage). Idle-retry both until recovery.
+
+### Correction (same session): cannot trim onlyoffice — recipe-as-is rule
+Investigated the "disable onlyoffice to shrink the stack" idea from the entry above. The lasuite-drive
+recipe ships a **single `compose.yml`** with collabora AND onlyoffice as unconditional services — no
+`COMPOSE_FILE`/compose-profile toggle in `.env.sample`. Disabling onlyoffice would require editing the
+recipe's `compose.yml`, which violates "test the recipe as-is / never modify the recipe under test"
+(§7-equivalent corner-cut). So **the trim avenue is closed** — I test all 12 services. The only
+legitimate levers for the rate-limit problem are: (1) **registry pull credentials** (the §1.5 operator
+finding — requested), and (2) **don't `docker image prune` aggressively** between runs (it forces cold
+re-pulls that burn the anonymous quota; let the cache persist). Disk pressure must instead be managed
+by pruning ONLY truly-dangling images, or by the operator growing the cc-ci disk.
+(Also noted: recipe env is `ONLY_OFFICE_DOMAIN`, underscore — my EXTRA_ENV flattened COLLABORA/MINIO
+domains but not onlyoffice's; only matters for the WOPI/TLS path, to revisit when base converges.)