feat: support the service hostname key

[lesnik512]

What

Accept the Compose service hostname key. Previously compose2pod rejected it
(service '<name>': unsupported key 'hostname'), which broke real CI compose
files that set a hostname (e.g. keydb: hostname: keydb-test-server-0) and
connect to the service by that name.

The hostname is folded into graph.hostnames(), so it becomes an
--add-host <hostname>:127.0.0.1 entry - resolvable to loopback in the pod's
shared network namespace, exactly like a network alias already is. No
per-container --hostname is emitted (pod members share the UTS namespace).

Why

The rejected name is load-bearing: the application connects to the service at
that hostname, so silently dropping it would emit a script that fails at
connect time. Full rationale, alternatives, and non-goals live in the change
file - this body does not restate them:

• Design/spec: planning/changes/2026-07-08.01-service-hostname.md
• Capability doc updated in this PR: architecture/supported-subset.md

Tests

just test-ci - 86 passed, 100% line coverage. just lint-ci clean. Coverage
at all three layers: validate acceptance (test_parsing.py), hostname
collection (test_graph.py, incl. empty-hostname guard), and end-to-end
validate -> emit_script rendering the --add-host entry (test_emit.py).