Add bounded Online Shop Compose runtime smoke validation #13

Goal

Add a bounded runtime smoke check for the digest-pinned Online Shop Compose configuration introduced in #11.

Static configuration checks are available. This task establishes whether the selected images can start together and serve a basic application flow.

Scope

• Consume the existing Compose renderer and explicit candidate/profile inputs.
• Require ordinary offline validation by default.
• Allow explicit inspection-only execution for the legacy baseline while preserving its negative validation result.
• Run the exact candidate images without builds, additional images or changes to image references.
• Use an isolated Compose project with bounded startup, readiness and smoke-check deadlines.
• Check frontend availability, product browsing, cart operations and a synthetic checkout.
• Collect concise diagnostics and clean up containers, networks and ephemeral data after success, failure or timeout.
• Produce a machine-readable report tied to the candidate content, inventory revision, Compose profile and exact image set.
• Document prerequisites, commands and limitations.

Acceptance criteria

• Runtime execution requires explicit opt-in; existing validation and rendering commands remain unchanged.
• Invalid candidates cannot start containers. Inspection-only permits exclusively the documented legacy-ineligibility failures.
• All 12 services use the exact candidate digest references; no application builds or auxiliary images are introduced.
• Frontend access remains loopback-only; no credentials, privileged containers or host bind mounts are required.
• Readiness and smoke checks have explicit deadlines and distinguish application failures from execution errors.
• Reports distinguish runtime success from release eligibility, approval and deployment authorization.
• Cleanup runs on success, failure, timeout and interruption without affecting unrelated Docker resources.
• Automated tests cover orchestration, failure handling, report semantics and cleanup.
• One bounded live baseline run is attempted; its result and any blocker are recorded accurately.
• Public documentation contains concise, sanitized results without machine-specific troubleshooting details.

Boundaries

Runtime success does not resolve historical source/build gaps or approve the legacy baseline.

Performance testing, Kubernetes deployment, SRE promotion, registry publication and mandatory runtime PR gates are outside scope.

Related to #11.