Migrate db-sync-tool/file-sync-tool integration to php-sync-tool

[konradmichalik]

Problem

database:backup, feature:sync and the three dev:* sync tasks (dev:sync, dev:dump, dev:import) all shell out to db_sync_tool/file_sync_tool, two Python packages (db-sync-tool-kmi, file-sync-tool-kmi) that consuming projects install via pip3 in their web container (see docs/FEATURE.md:42-46). That means every project using this toolset needs a Python toolchain in its container just for the sync step.

konradmichalik/php-sync-tool is a PHP/Composer-native replacement (same maintainer), already largely CLI/config-compatible with db-sync-tool, with file sync integrated (no separate file_sync_tool binary needed) and TYPO3/Symfony/Drupal/WordPress/Laravel credential auto-detection. It removes the Python dependency entirely, projects just need composer require --dev konradmichalik/php-sync-tool.

Migration is currently blocked by four gaps found while piloting this in verdi-bb-website-typo3, tracked upstream:

• konradmichalik/php-sync-tool#31 — custom TYPO3 .env variable names (db.name: TYPO3_DB_NAME style, used in our configs) were silently misread. Fix open as PR #39.
• konradmichalik/php-sync-tool#32 — --use-rsync, passed by database_backup.php:21 and feature_sync.php:129, isn't recognized.
• konradmichalik/php-sync-tool#33 — no -kd <dir>/-dn <name> equivalent for dev:dump (dump.php:22).
• konradmichalik/php-sync-tool#34 — glob origin paths in files: blocks (fileadmin/*, used in every one of our configs) not yet verified to behave like file-sync-tool's.

Proposal

Binary resolution: auto-detect, no per-project setting

db_sync_tool/file_sync_tool are global PATH binaries (pip-installed). vendor/bin/sync-tool is a project-local Composer binary, a materially different resolution model, and not every one of the ~8 downstream projects will migrate at the same time.

Rather than a flavor toggle each project has to opt into via its deploy.php, resolve the binary automatically:

function resolveSyncTool(string $legacyBinary, string $phpBinary = 'vendor/bin/sync-tool'): string
{
    return test('[ -x '.$phpBinary.' ]') ? $phpBinary : $legacyBinary;
}

A project migrates by running composer require --dev konradmichalik/php-sync-tool, nothing in deploy.php needs to change. commandExistLocally() (deployer/functions.php:129-132) uses bash's hash builtin, built for PATH lookups; whether hash vendor/bin/sync-tool (a relative path with a slash) resolves reliably needs verifying before relying on it, test -x is the safer primitive either way.

The six call sites

File	Today	Change
deployer/sync/task/database_backup.php:16	{{db_sync_tool}} -f {{sync_database_backup_config}} --use-rsync -y	resolve binary; drop --use-rsync once on the PHP tool (rsync is its default)
deployer/feature/task/feature_sync.php:129	{{db_sync_tool}} -f {{feature_sync_config}} --target-path {{feature_sync_target_path}} --use-rsync -y	same
deployer/feature/task/feature_sync.php:142-152	separate {{file_sync_tool}} -f ... --files-target ... call	remove entirely, add --with-files to the db call above when running on the PHP tool (php-sync-tool has file sync integrated)
deployer/dev/task/sync.php:51	literal db_sync_tool -f ... -y $additionalOptions, no guard	resolve binary, add the commandExistLocally/test -x guard the other tasks already have
deployer/dev/task/dump.php:22	literal db_sync_tool -f ... -y -kd $dbDumpDir -dn $dbDumpFilename, no guard	resolve binary + guard; -kd/-dn need php-sync-tool#33 first, until then fall back to dump_dir from the YAML config when running the PHP tool
deployer/dev/task/import.php:12	literal db_sync_tool -f ... -y -i $dbDumpDir/$dbDumpFilename.sql, no guard	resolve binary + guard, -i already works on both

The three dev:* tasks having no existence guard at all is an existing bug independent of this migration, worth fixing regardless.

Settings

• deployer/sync/config/set.php:5, deployer/feature/config/set.php:26 — db_sync_tool stops being a plain string default and becomes the resolved value (see above).
• deployer/feature/config/set.php:27 — file_sync_tool setting can be removed once the file-sync call is folded into --with-files.
• deployer/requirements/config/set.php:29-40 — currently checks rsync, curl, gs, git, gzip, mysql, unzip, patch, exiftool, composer but never the sync binary itself. Add a check here so a missing sync tool fails fast at requirements, not mid-deployment.

Docs

docs/FEATURE.md:42-46 documents pip3 install db-sync-tool-kmi file-sync-tool-kmi. Needs a note that composer require --dev konradmichalik/php-sync-tool is now the preferred path, with the pip install kept as the legacy fallback until every project has migrated.

Why

Removing Python from the container is the actual motivation (see verdi-bb-website-typo3's .ddev/web-build/Dockerfile:4-14, which installs python3-pip solely for these two packages). Auto-detection lets each of the ~8 downstream projects migrate independently, on their own schedule, without deployer-tools forcing a synchronized cutover or every project needing a deploy.php change to opt in.