Gotify: add optional iGotify container

[jackspiering]

Description

Adds an optional igotify container to the Gotify stack, so iPhone and iPad users get push notifications through the iGotify app. Gotify has no iOS app of its own.

• The container only runs with the igotify Compose profile (COMPOSE_PROFILES=igotify in .env). Without it, the stack behaves as before.
• It shares the Tailscale sidecar's network and uses iGotify's "local instance" mode. Gotify stays reachable only through the Tailnet, and GOTIFY_URLS is http://127.0.0.1:80, pre-filled in .env.
• Why this is not a separate service: iGotify has no Tailscale support and always needs a Gotify server, so it fits beside Gotify behind the same sidecar. A separate stack would need MagicDNS and ACL access between two devices.
• iGotify's image is ghcr.io/androidseb25/igotify-notification-assist:latest (upstream publishes latest and exact vX.Y.Z.W tags and recommends latest).
• The README gets a "Configuration" section with the setup steps, the deviations, and a note on the data path: messages are encrypted and forwarded through the SecNtfy relay and Apple's push service, so they leave the Tailnet.

Sources: iGotify README, its wiki, and its docker-compose.yaml.

Related Issues

• Closes 🏗️ New Service: iGotify #303

Verification

• docker compose config --quiet from services/gotify, with dummy values for required variables, with and without --profile igotify
• The stack started, Tailscale is healthy, and the service is reachable through the Tailnet (Serve checked from inside the namespace: /health returned 200)
• The main function of the service works, and its data survives a restart. Partly run, see below.
• rumdl check --config .markdownlint.yml . (0.2.78) on the whole repository, and git diff --check origin/main

Live test with a scratch copy and a test auth key:

• Gotify, igotify, and the sidecar all became healthy. The igotify health check (curl -fs http://127.0.0.1:8080/Version) was run in the container and returned 200.
• iGotify connected to Gotify's WebSocket at ws://127.0.0.1/stream with a client token created through the Gotify API.
• A message posted to Gotify reached iGotify, which tried to forward it to SecNtfy. SecNtfy answered Unauthorized because I used a dummy SecNtfy token.
• After docker compose restart and after down and up -d, the Gotify message, users.db, and the iGotify WebSocket connection survived.
• A plain docker compose down removes the igotify container only while COMPOSE_PROFILES=igotify is set. The README says so.

Not run: delivery to a real iPhone. That needs the iGotify app and a SecNtfy token from it, and I have no iOS device. The test above ends at SecNtfy's rejection of the dummy token.

Impact on existing users

• None. The container is opt-in. .env gains empty COMPOSE_PROFILES, GOTIFY_CLIENT_TOKENS, and SECNTFY_TOKENS values, GOTIFY_URLS=http://127.0.0.1:80, and an IGOTIFY_IMAGE_URL, none of which change a Gotify-only stack.

Checklist

• I have performed a self-review of my code and followed the templates structure.
• I did not commit a working auth key, password, token, or other credential.
• The service README uses the headings of the template, in the same order, and is up to date.
• I added, removed, or renamed the service in the root README.md, in alphabetical order, or this PR does not change the list of services.

Additional Context

• The extra container is listed under "Deviations from the standard setup". It is named app-${SERVICE}-igotify, as CONTRIBUTING.md suggests for extra containers.
• The image has no HEALTHCHECK, so the compose file calls iGotify's version endpoint with curl, which ships in the image.