0.1.2

compose2pod 0.1.2 — accept the service hostname key

A patch release that stops rejecting valid compose documents which set a
service hostname. The validator was over-strict: a service carrying
hostname: — used to give a service a stable name that other services connect
to — raised unsupported key 'hostname'. Such documents now convert.

Fix

• The service hostname key is accepted. validate() no longer rejects a
  service that sets hostname:, and the hostname is made resolvable to
  127.0.0.1 inside the pod, exactly like a network alias: it joins the
  --add-host set so other services reach the service by that name. Because all
  services share one network namespace (and the pod's UTS namespace), only name
  resolution is meaningful — no per-container --hostname is emitted.

Downstream

No action needed — additive and backward compatible. Documents that previously
failed with unsupported key 'hostname' now emit a pod script; nothing that
converted before changes.

Internals

• architecture/supported-subset.md adds hostname to the supported
  service-key matrix with the shared-namespace resolution rationale.
• 86 tests at 100% line coverage (enforced); ruff select=ALL, ty, and
  eof-fixer clean.