Create a separate project for launching mock deployments with Docker and Apple container #3724

Closed as not planned (2026-10-29). Cloud Image Recognition and cloud image target management are being removed in #3831 following PTC's announced May 2, 2027 retirement. This proposal specifically requires a new launcher for the existing three-service deployment, including VWQ, cloud database setup, image upload/query, and recognition reports. That deployment and workflow will no longer be supported, so this proposal is obsolete in its current form. Any future launcher for the retained Model Target and VuMark services should be scoped around their remaining deployment requirements.

The native Apple container quickstart currently requires users to create a network, start three containers, discover the target manager's IP address with container inspect and jq, pass that address to VWS and VWQ, and run readiness probes. This wiring should be handled by a launcher so that users can start a mock without copying address-parsing commands.

Create this as a separate project and repository, with its own packaging, releases, documentation, and tests. The launcher should use the existing published mock images and preserve the three-service deployment. It should not become a runtime adapter inside vws-python-mock or require Socktainer for Apple deployments.

Proposed interface (command name subject to the new project's naming):

mock-vws up --runtime apple
mock-vws down --runtime apple
mock-vws up --runtime docker
mock-vws down --runtime docker

Acceptance criteria:

• Support Docker and Apple's native container CLI through their public interfaces.
• Create the deployment network, start target manager first, discover its address as needed, and configure VWS and VWQ automatically.
• Default to loopback bindings on host ports 5005 (target manager), 5006 (VWS), and 5007 (VWQ), with configurable ports and a configurable public VWS URL for report downloads.
• Wait for all three services to become usable through their published host ports before reporting success. Use a bounded timeout and include useful service logs on failure.
• Report the three service URLs and provide a short database-creation example.
• Clean up resources created by a failed startup. down should remove only resources owned by the named deployment and be safe to run repeatedly; do not remove unrelated resources. Support named deployments so users can run more than one mock with different ports.
• Keep installation straightforward and document host prerequisites. Users should not need to install jq, write host-side Python, or manage inter-container addresses themselves.
• Verify both runtimes using real deployments: database creation, signed VWS requests, target upload/processing, a matching VWQ query, report download URLs, and cleanup. Cover startup failure, timeouts, resource-name collisions, and repeated shutdown without weakening the existing vws-python-mock deployment tests.
• Once the launcher is released and verified, update vws-python-mock documentation to link to it as the simple setup path. Retain the native CLI instructions for users who want to manage the containers directly.

This issue tracks creating the separate project and integrating its released launcher into the documentation; it does not propose combining the three services into one container.