feat(engine): option to drop compose host port publishing

[bilby91]

Closes #135.

EngineOptions.DisableHostPortPublishing drops the host side of compose
ports: entries. Services still start and nothing else about them changes;
each dropped entry raises an engine.warn event
(compose_host_port_publish_skipped) naming the service and where it is
reachable, so the user can delete the entry rather than wonder why it did
nothing.

Design decisions

Naming: DisableHostPortPublishing, not SharedHostNamespace. The issue
left this open, with the why-name reading better if network_mode: host later
joins the same option. I drafted it that way first and it misread immediately —
an option called "shared host namespace" sounds like it puts the engine on
the host's namespace, which is the opposite of what it does. The what-name says
what changes; the why lives in the doc comment.

Dropped from the in-memory project, not inside the orchestrator's
portsOf. The issue suggested portsOf returns nil. ConfigHash hashes the
project's ServiceConfig, so a drop there is invisible to the recreate check:
a container created before the option was turned on would keep its publishes
and be reused. Removing the entries from the project instead makes the hash
move, which is the correct behaviour and a deliberate recreate trigger (R3) —
turning the option on replaces the containers of services that declare
ports:. This also reuses the existing seam: compose.ApplyDropHostPorts
sits next to ApplyBuildOverride / ApplyRunOverride, whose whole job is
mutating the project before the orchestrator reads it, and keeps the
orchestrator free of a new option and a new warning channel (it has no event
surface today; the engine already has one).

Entries are removed whole, including ones with no published.
ports: ["8080"] binds an ephemeral host port — same namespace, same problem.

Shellout is refused, not silently ignored (R2). That path hands the user's
compose files to docker compose, which publishes ports: regardless, and
stripping them there would mean re-implementing merge / extends / override
resolution against the YAML. A compose-source Up under
ComposeBackendShellout with the option set returns an error naming the
backend that honours it. The failure the option exists to prevent is a
boot-time bind collision, which is worse to debug than a refusal at the top of
the call.

network_mode: host is not covered. Same collision, but a drop is not
available: silently moving the service to a bridge network changes
reachability. It wants a plan-time refusal, which needs the option to reach
Plan.Validate. Filed as #136 with the shape left open.

Tests

• compose/apply_drop_host_ports_test.go — every entry on every service goes,
  in sorted service order (warning order must not depend on map iteration);
  published-less entries are dropped and rendered without a host side;
  nothing but ports: moves; and the ConfigHash pin for the paragraph above.
• up_compose_host_ports_test.go — the consumer check (R1): the option reaches
  RunSpec.Ports at the backend boundary, not just the project; the warning
  fires and names the service, the entry, and the address to use instead; the
  publish still reaches the backend by default; shellout refuses. Reverting the
  call in upComposeNative fails the first of these.
• test/integration/compose_host_port_publishing_test.go — a real daemon boots
  a project whose primary publishes a port with the option on, and the sidecar
  is still reachable by service name over the compose network. That is the half
  a fake cannot make, and it is the claim the whole design rests on. What the
  host binding does or does not do is asserted at the RunSpec boundary above;
  RunSpec.Ports → docker PortBindings translation is already covered in
  runtime/docker.

make lint test green. Integration tests were not run locally — overlayfs
is unusable in this devcontainer, so the pre-existing suite fails there the same
way (mount source: "overlay" … invalid argument); they run in CI.

🤖 Generated with Claude Code

[bilby91]

@dap-code-review-by-crunchloop review

The check for this head reported "Review did not complete" — nothing was published for 41799df, so this is a re-request on the same commit rather than a response to findings.

[dap-code-review-by-crunchloop]

On it. A review of the current head is on its way.