feat: accept and ignore the service-level profiles key

[lesnik512]

Summary

Accept a service-level profiles: key instead of hard-rejecting it. A profiled service is now accepted, warns service '<name>': ignoring 'profiles', and has no effect on the emitted script.

Design: planning/changes/2026-07-10.04-profiles.md.

Why ignore is the faithful mapping (not a cop-out)

compose2pod's run set is fully determined by --target plus its depends_on closure (startup_order), with no docker compose up-style "start all active services" mode. Two Compose rules make ignoring profiles correct here:

• Targeting a service by name auto-activates its profile (Compose: "when you explicitly target a service ... you do not need to enable the profile manually"). So --target X on a profiled X runs X, exactly as Compose would.
• A service outside the target's closure never runs regardless of its profile; a service inside the closure is a hard depends_on dependency that must run. Either way profiles changes nothing about what compose2pod emits.

Previously profiles was in none of the accepted sets, so _validate_service raised unsupported key 'profiles' and any real compose file using profiles failed to convert.

Change

One production line: add "profiles" to IGNORED_SERVICE_KEYS in compose2pod/parsing.py (joining ports, restart, stdin_open, tty, stop_signal, stop_grace_period). No changes to emit.py, graph.py, keys.py, store.py, or the CLI. No --profile flag and no shape validation of profiles — both deliberate non-goals (no observable effect in the single-target model; consistent with the other never-emitted ignored keys).

Documented divergence

If the target depends_on a member whose profile Compose would leave disabled, compose2pod runs it anyway (the closure is authoritative). This matches the user's explicit depends_on intent and compose2pod's "run the target plus its dependency closure" contract — it is more permissive than Compose, never a silent drop. Recorded in architecture/supported-subset.md.

Testing

just test-ci at 100% coverage (267 tests), just lint-ci clean, just check-planning OK. New tests: validate() accepts and warns; the emitted script is byte-identical with vs without a profiles key on an in-closure service (proving inertness); a profiled service outside the closure is not run (asserted via the container name test-pod-debug-tools, since every service name still appears as an --add-host alias); and --target on a profiled service still emits it.