Technitium: store settings and zones on the host

[jackspiering]

Description

Technitium keeps its settings, zones, logs, and statistics in /etc/dns. The stack mounted the data folder at /config, which Technitium does not use. The host folder stayed empty, and everything was lost when the container was recreated, for example after an image update.

• compose.yaml: mount ./${SERVICE}-data/app/config at /etc/dns.
• README.md (service): list the data folder, remove the data-loss warning, and add an "Upgrading" section. Existing installations have their settings inside the container, so the section explains how to copy them to the host before the first start of the new version.

Related Issues

• None.

Verification

Tested in a scratch copy with technitium/dns-server:latest. A stand-in container replaced Tailscale, because the test only concerns the volume.

Step	main	This branch
Create a zone, then recreate the container	Zone is gone, host folder has 0 files	Zone is still there
docker compose down, then up -d	Zone is gone	Zone is still there
New installation: create a zone, recreate the container	Zone is gone	Zone is still there, host folder has 13 entries

Upgrade path from the README, starting on main with a zone probe5.example and an A record www.probe5.example:

1. docker compose stop application
2. docker cp app-technitium:/etc/dns/. ./technitium-data/app/config/
3. docker compose up -d with the file from this branch

Result: the zone is listed, and nslookup www.probe5.example 127.0.0.1 in the stack returns 192.0.2.10.

A copy from the running container with docker exec … cp missed the zone, because Technitium writes zone files with a delay. The README therefore stops the container first.

• docker compose config --quiet in services/technitium: passed.
• rumdl check --config .markdownlint.yml services/technitium/README.md: passed.
• git diff --check: passed.

Not tested: access through the Tailnet, which this change does not touch.

Checklist

• I have performed a self-review of my code and followed the templates structure.
• I have added verification that the stack works as expected.
• I have updated necessary documentation (e.g. frontpage README.md ).
• I have selected the correct label(s) for this PR.

Additional Context

• This pull request is stacked on All services: standardize the service READMEs #363 and targets its branch, because it edits the new README. Merge All services: standardize the service READMEs #363 first.
• The test host has no sudo, so step 2 ran after a chown of the host folder. The README uses sudo docker cp, because Docker creates the folder as user root.