Add DOCKER_GID runtime customization

[umputun]

Problem

When mounting the docker socket with a different GID on the host (e.g., 123, 998), the container's default docker group (GID 999) doesn't match, causing socket access failures. The --group-add docker flag doesn't help because su-exec drops supplementary groups.

Solution

Add DOCKER_GID environment variable handling to init.sh, similar to existing APP_UID handling:

• Check if DOCKER_GID differs from default 999
• If another group already uses that GID, add app user to that existing group
• Otherwise, recreate docker group with requested GID
• Includes error handling for group operations

Usage

# find host docker GID
stat -c %g /var/run/docker.sock  # Linux

# run with matching GID
docker run -e DOCKER_GID=998 -v /var/run/docker.sock:/var/run/docker.sock <image>

Related to umputun/updater#48

[Copilot]

Pull request overview

This PR adds runtime customization for the docker group GID to support mounting the docker socket when the host's docker group has a non-default GID. This addresses permission issues that occur when the host's docker socket GID differs from the container's default (999).

Changes:

• Added DOCKER_GID environment variable handling in init.sh with intelligent GID collision detection
• Updated README with DOCKER_GID documentation and usage examples for Linux/macOS
• Updated CLAUDE.md to reflect the new docker GID setup functionality

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
base.alpine/files/init.sh	Implements DOCKER_GID customization logic with collision handling and error checking
README.md	Documents DOCKER_GID variable and provides usage examples with host GID detection commands
CLAUDE.md	Updates entrypoint script description to include docker GID setup

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The GID collision handling (lines 27-33) adds the app user to an existing group with the requested GID rather than to the docker group. While this correctly achieves socket access through matching GIDs, this behavior might be unexpected to users who assume the app user will always be in the docker group. Consider adding a note to the README documentation explaining that in case of GID collisions, the app user will be added to the existing group with that GID instead of recreating the docker group.

Suggested change

	**Note on GID collisions**: If a group with the requested `DOCKER_GID` already exists inside the container, the `app` user will be added to that existing group instead of creating or renaming a group explicitly called `docker`. Socket access is still granted via the matching GID, but the group name may differ from `docker`.