feat: accept compose x- extension fields

[lesnik512]

Summary

compose2pod rejected any top-level key it did not explicitly support, so a compose document carrying a Compose extension field — e.g. x-application-defaults holding a YAML anchor for reuse — failed with unsupported top-level keys: ['x-application-defaults']. The Compose spec reserves the x- prefix for arbitrary user data that tools must ignore.

This teaches validate() to skip any x--prefixed key silently at every mapping level it inspects: top level, service, and healthcheck. PyYAML's safe_load already resolves &anchors and <<: merge keys at load time, so no code is needed for those — the only blocker was the leftover top-level x- key.

Changes

• compose2pod/parsing.py: x- skip in the three key-validation loops; the top-level unknown-key check becomes a comprehension that also drops x- keys. _validate_service was split into _validate_service_healthcheck / _validate_service_volumes helpers (behavior-preserving) to stay under ruff's McCabe limit once the extra branches were added.
• Tests: three unit tests (top-level / service / healthcheck, incl. a warnings == [] guard for the silent decision) plus an end-to-end YAML-anchor test through _read_compose -> validate -> emit_script.
• Docs: new architecture/supported-subset.md capability file (the accept/ignore/reject matrix, incl. the note that build is accepted but never built — image_for substitutes --image); README subset section updated to point at it.

Planning

Full-lane change bundle: planning/changes/2026-07-04.01-extension-fields/ (design + plan).

Verification

• just test-ci: 82 passed, 100% line coverage.
• just lint-ci: clean (ruff select=ALL --no-fix, format, ty, eof-fixer, planning).