[BUG] develop.watch initial_sync: true does not fire at container start

[mecampbellsoup]

Description

develop.watch entries with initial_sync: true do not copy files from host to container at container creation time. Change-triggered syncs work correctly — only initial_sync is affected.

Steps To Reproduce

docker-compose.yml:

services:
  test:
    image: python:3.14-slim
    command: sleep infinity
    develop:
      watch:
        - path: ./src
          action: sync
          target: /app/src
          initial_sync: true

mkdir -p src && echo "hello" > src/test.txt
docker compose up --watch -d
sleep 30
docker exec <container> ls /app/src/   # → "No such file or directory"

# But change-triggered sync works:
touch src/test.txt
sleep 10
docker exec <container> ls /app/src/   # → test.txt appears

Observed Behavior

• Container starts and runs successfully
• ⦿ Watch enabled message appears in compose output
• /app/src/ does NOT exist inside the container after 30+ seconds
• After touching src/test.txt on the host, compose watch detects the change and syncs — /app/src/test.txt appears

Expected Behavior

With initial_sync: true, files should be copied from host to container at compose startup, before the main process starts. Per the documentation: "If initial_sync is set to true, Compose copies the watched files to the container when the service is started."

Environment

• Docker Desktop for Mac (Apple Silicon)
• Docker Compose v2.35+ (tested with latest stable as of 2026-04-10)
• macOS 15.4 (Darwin 25.4.0)
• Reproducible across multiple compose projects and file types

Notes

• sync entries for individual files (e.g., pytest.ini → /app/pytest.ini) DO work with initial_sync: true
• sync entries for directories (e.g., docker/pythonocc → /app/docker/pythonocc) do NOT fire initial_sync
• The distinction may be file vs. directory syncing behavior

[trinhchien]

I was able to reproduce this locally and traced it to initialSyncFiles() in pkg/compose/watch.go.

initial_sync was filtering files using the image creation time, so existing host files could be skipped during startup sync if their mtime was older than the image. That matches the behavior described here: startup sync is empty, but change-triggered sync works after touching the file.

I opened a fix here: #13728

The patch removes the image-time filter for initial_sync and adds tests for both directory and single-file watch paths.