threads-profile: drop --no-sandbox, re-enable Chromium's own sandbox

Verified live on prod (systemd-run with the same User=harbor,
NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true,
ReadWritePaths=/var/lib/harbor as harbor-worker@.service) that Chromium's
unprivileged-userns sandbox launches and navigates fine without
--no-sandbox; kernel.unprivileged_userns_clone=1 on this host makes it
unnecessary. Keeping the browser's own renderer/GPU sandbox gives real
defense-in-depth against a malicious/compromised public Threads page,
instead of relying on systemd's process-level ProtectSystem alone.

Needs a normal release (build-release.sh + activate-release.sh) to reach
prod; not hot-patched on the live host.

Co-authored-by: Cursor <cursoragent@cursor.com>

apps/backend/scripts/threads-profile/scrape.mjs

@@ -73,9 +73,13 @@ async function main() {
     }
   }
 
+  // No --no-sandbox: verified Chromium's own unprivileged-userns sandbox
+  // launches fine under the worker's systemd hardening (NoNewPrivileges=true
+  // + ProtectSystem=strict), so keep the renderer/GPU process sandboxed
+  // instead of trusting ProtectSystem alone against untrusted public pages.
   const browser = await chromium.launch({
     headless: true,
-    args: ["--disable-blink-features=AutomationControlled", "--no-sandbox"],
+    args: ["--disable-blink-features=AutomationControlled"],
   });
 
   try {