HEALTHCHECK compatibility boundary: standalone Docker to Swarm transition for zero-downtime migration

A small application is being prepared for a zero-downtime migration, and its image includes a HEALTHCHECK. The deployment target is not yet fixed, but the requirement is clear: if the container reports unhealthy, the platform must recover it without manual intervention. In standalone Docker, the daemon marks the container unhealthy but does not stop or restart it, and restart policies do not react to health status. Swarm mode behaves differently by allowing health check failures to influence task replacement. Because health-check semantics and Compose deploy key handling have changed across Docker Engine releases, the exact boundary between these behaviors depends on the version in use.

Before committing to an architecture, we need to resolve whether a standalone deployment can make HEALTHCHECK status actionable through documented configuration alone, or whether the only supported path is to move the workload into Swarm or an external orchestrator. If Swarm is required, which version-specific health-check behaviors should be verified to ensure the migration does not introduce unexpected rescheduling delays or gaps?