0.4.2

compose2pod 0.4.2 — a container can resolve its own hostname again

A second follow-up to the 0.4.0 owned-/etc/hosts work: restore resolution of
a container's own hostname inside the pod, which --no-hosts silently
dropped. Images whose startup resolves their own hostname — a KeyDB-sentinel
image, anything running hostname -f — no longer crash-loop.

Fix

• The pod gets a resolvable hostname. 0.4.0 moved name resolution into a
  script-owned /etc/hosts under --no-hosts to kill the pre-6.0.0 stop-wipe
  bug — but --no-hosts also stops Podman from adding each container's own
  hostname line. The hostname is then the random container ID, absent from the
  owned file, so hostname -f fails with Temporary failure in name resolution and an image whose startup resolves its own hostname crash-loops
  and never goes healthy (a depends_on: service_healthy on it then times
  out). The generated script now passes podman pod create --uts private --hostname <pod-name> and adds 127.0.0.1 <pod-name> to the hosts file, so
  the hostname resolves. --uts private is required — in the host UTS
  namespace Podman refuses --hostname. Verified end-to-end on real Podman
  5.8.1 and 6.0.1.

Why

This is a straight regression from 0.1.8, which used no --no-hosts and let
Podman populate /etc/hosts — including the own-hostname line — so a
self-referential image worked. 0.4.0 owned the file to gain version-independent
resolution and non-root readability (0.4.1), but did not re-add the one line
Podman contributed beyond the alias set. A pod shares a single UTS namespace,
so per-service hostnames are physically impossible; the pod name is one shared,
resolvable hostname, which is all a hostname -f lookup needs (0.1.8 worked
with a random container-ID hostname, so the specific value never mattered).

Downstream

• No action needed beyond re-running compose2pod at 0.4.2 (the fix is in
  the emitted script). Compose files with a self-referential image that hung on
  0.4.0/0.4.1 now start. Per-service hostname: keys behave exactly as before:
  resolvable by peers via /etc/hosts, not set as a container's own name.

Internals

• Tests at 100% line coverage (enforced); ruff select=ALL, ty, eof-fixer
  clean; conformance (real Docker CLI) and integration (real Podman) harnesses
  green. Reproduced on Podman 5.8.1 via quay.io/podman/stable:v5.8.1 and on
  6.0.1: a service whose healthcheck is hostname -f goes healthy, and a peer
  resolves its own hostname. Confirmed in passing that the JSON-array
  --health-cmd compose2pod emits for a ["CMD", ...] healthcheck is accepted
  by Podman 5.8.1 — that rendering was never the bug.