No macOS installer: install-langtechdepot.sh is Linux-only

#2 has "Test receiving on Mac" unticked, but there is nothing behind it to test: client/install-langtechdepot.sh cannot run on macOS. Raising it so the checkbox isn't mistaken for pending testing when it is actually pending an installer.

First, a scope question. CLAUDE.md describes the audience as "~50 field machines on low-bandwidth links, Windows and Linux". If that is still accurate, the right resolution here may be to drop the Mac line from #2 rather than write a third installer. Everything below assumes we do want Mac.

What blocks it today

1. Asset filter is Linux-only. The download picks linux-$st_arch-…tar.gz. macOS builds are named and packaged differently — from v2.1.5:

   syncthing-macos-amd64-v2.1.5.zip
   syncthing-macos-arm64-v2.1.5.zip
   syncthing-macos-universal-v2.1.5.zip
   

   Different platform token and .zip instead of .tar.gz, so the existing curl … | tar -xz pipe doesn't apply either. macos-universal would avoid having to choose per-architecture.
2. uname -m case doesn't cover Apple Silicon. It handles x86_64, aarch64, armv7l; macOS reports arm64, which falls through to unsupported architecture.
3. No systemd. The install writes a systemd user unit and calls systemctl --user and loginctl enable-linger. macOS needs a launchd LaunchAgent plist in ~/Library/LaunchAgents plus launchctl, which is a different enough shape that it wants its own script rather than branching this one.
4. python3 is not shipped by default. The script uses it for XML and JSON parsing. On macOS it arrives with the Xcode command line tools, so it cannot be assumed on a fresh machine — which matters for field users without admin rights.

What is already fine

• Config location is a non-issue now: d048569 pins --home, so we no longer care that Syncthing would otherwise use ~/Library/Application Support/Syncthing.
• The registration flow, receive-only defaults, and introducer setup are all REST calls and platform-neutral.
• Homebrew (brew install syncthing) would be the natural analogue of the Windows winget path — a packaged install we don't have to download ourselves.

Suggested shape, if we go ahead: a separate client/install-langtechdepot-macos.sh that reuses the REST half verbatim and swaps the three platform pieces (asset name, unzip, launchd). This also interacts with #9: Mac home directories routinely contain spaces ("/Users/First Last"), and the systemd unit's unquoted binary path has the same weakness, so #9 wants fixing first.

Not urgent unless a Mac field machine is actually waiting on it — flagging mainly so #2 reflects reality.

First resolve whether macOS support is still in scope using the audience described in CLAUDE.md and the dependency on issue #9. Then read client/install-langtechdepot.sh and d048569, comparing the existing REST flow with the platform-specific installer steps described here. Done means a separately scoped macOS installation path, or a documented decision to remove Mac testing from #2.