A Pi gets the unpacked path, not a dead end

Chrome is x86_64 only on Linux and Chromium cannot be enrolled, so on ARM the
enrolment step can never succeed. Removing load-unpacked from the installer
left those machines being told to run a script that would refuse - setup now
detects the architecture, explains why, and the summary points at the unpacked
install, which on that hardware is not a fallback but the only thing that
works. It still self-updates.

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

README.md

@@ -149,6 +149,14 @@ from Google's own enterprise MSI on Windows and the official .deb on Linux;
 Chromium is not accepted as a substitute, because it has no cloud-management
 support and can never be enrolled.
 
+**On a Raspberry Pi, none of that applies.** Google publishes Chrome for x86_64
+only, so an ARM box has Chromium and nothing else, and Chromium cannot be
+enrolled. There the extension is loaded unpacked — `chrome://extensions` →
+Developer mode → Load unpacked → `extension/` — and updates still arrive,
+because an unpacked copy reloads itself from disk when the dashboard reports a
+newer version. `setup-linux.sh` detects the architecture and says so rather than
+offering an enrolment that cannot work.
+
 **Enrolment is not optional.** No Chromium browser will force-install an
 off-store extension on an unmanaged machine, whatever the registry says — it
 reads the policy and blanks it. Enrolling is what makes Chrome managed without