fix(docker/container): configuration change does not result in update/replacement

[Gerbuuun]

Problem

Docker.Container can report a successful update without applying the resolved configuration to Docker.

When a container prop depends on an Action or another resource output, Container.diff cannot compare it during planning because the new props are still unresolved. The planner schedules an update, but the old reconciler only synchronized networks and start state. Create-time settings such as environment variables, commands, ports, volumes, labels, restart policy, and health checks could remain unchanged while Alchemy persisted the new props.

A related case occurs when Docker.Image rebuilds an image under the same tag. The imageRef remains unchanged even though the imageId changes, so a dependent container could continue using the old image.

Fix

• Hash the fully resolved Docker create arguments together with the managed image ID and stamp newly created containers with that internal configuration hash.
• During reconcile, recreate a container when its applied hash differs from the desired hash.
• Keep a narrow compatibility path for containers created before the hash label existed, so upgrades and adoption do not replace otherwise matching containers.
• Treat adoption as already being in the desired Docker context, avoiding cleanup against the active/default context.
• Remove the previous container when a resolved name or context changes, including when two contexts point to the same engine.
• Continue applying network and start-state changes in place so those updates preserve the container ID.

The regression coverage includes Action-backed environment updates, same-ref image rebuilds, named-context adoption, host-bound ports during network-only updates, creating-state recovery with removed environment values, and start/network updates that must preserve the container.