docker: fix GID collision and macOS sed portability

Two host-environment bugs in the build-env scripts that break on
macOS/Apple Silicon hosts, independent of target architecture:

- Dockerfile: groupadd fails outright when USER_GID collides with an
  existing system group in the rockylinux9 base image (e.g. macOS
  default user GID 20 "staff" collides with RHEL's GID 20 "games").
  Guard with getent so useradd attaches to the existing group instead.
- ifcos_env: `sed -si` is GNU-only syntax and errors under BSD/macOS
  sed. Do the UNIQUE_ID substitution via a portable temp-file + mv.

Per sboddy's review on the original PR: dropped the linux/amd64
platform-pin additions from this change. The stack already targets
Rocky9/x64 build outputs by design, and Docker Desktop on macOS has
no native container runtime regardless (it's a Linux VM either way),
so forcing the image to run under emulation doesn't produce anything
that's actually loadable into a native macOS Blender/Bonsai install.
That's a separate, harder problem worth solving via a native build
path instead (mirroring build_osx.yml), not by fighting emulation
here. These two fixes stand on their own merits on any host.

This change was made with the assistance of an AI tool.

(cherry picked from commit 8b05510d6c)

docker/compose.yaml

@@ -4,14 +4,6 @@ services:
     container_name: ifcopenshell-${UNIQUE_ID}
     image: ifcopenshell-build-env:updated
     platform: linux/amd64
-    # There's no `build:` section - the image is always produced ahead of
-    # time by `./ifcos_env create` (`docker build`, not `docker compose
-    # build`). Without this, a platform mismatch between the pin above and
-    # whatever's in the local image store makes compose treat the image as
-    # absent and fall back to pulling ifcopenshell-build-env:updated from
-    # Docker Hub, where it doesn't exist. Fail fast with a clear "not
-    # found" instead of an obscure registry access-denied error.
-    pull_policy: never
     volumes:
       - type: bind
         source: ../