fix: advertise host services correctly to Docker conversations

Steps to Reproduce

1. Start agent-canvas with OH_CONVERSATION_RUNTIME=docker and Automation enabled.
2. Start a conversation.
3. From that conversation container, resolve host.docker.internal and request /api/automation/health at the runtime-service URL advertised by Canvas.

Actual Behavior

Canvas advertises localhost, which points to the child Agent Server and returns 404. The host ingress is reachable by its Docker bridge IP, but host.docker.internal is not defined.

Expected Behavior

The SDK should give Docker conversations a stable host.docker.internal host-gateway alias. Canvas should advertise host-side services using that alias and route Automation requests through its existing ingress. Local conversations should continue using localhost.

Acceptance Criteria

• The published Canvas CLI advertises host-side runtime services through host.docker.internal when OH_CONVERSATION_RUNTIME=docker.
• Local conversation mode continues to advertise localhost.
• Agent Server itself remains advertised at the child container's loopback URL.
• Focused tests cover both runtime modes.
• Live Docker conversation evidence shows /api/automation/health succeeds at the advertised URL.

Dependency

Requires OpenHands/software-agent-sdk#5164 to map host.docker.internal to Docker's host-gateway in each conversation container.

Start at the published Canvas CLI path that selects the Docker and local conversation runtimes, then trace how runtime-service URLs and the Agent Server URL are advertised. Check the focused tests for both runtime modes and verify the Docker host-gateway dependency is available. Done means Docker advertises host-side services through host.docker.internal, local mode keeps localhost, and the live Automation health request succeeds.