[codex] Heal remote clone branch boot dependencies

[adamziel]

What it does

Makes forkpress remote clone --branch ... verify that the new branch homepage boots before reporting success, then repairs the common thin-clone failure where WordPress needs a file from an initially excluded boot tree such as wp-content/uploads/.

When the smoke test reports a missing boot dependency under a managed excluded directory, ForkPress now rsyncs only that relative path into the remote cache, recreates the branch, and smoke-tests it again.

Rationale

The reproduced failure was not just “remote clone should fail more clearly.” A remote site can boot successfully while the default thin clone skips wp-content/uploads/; if an active plugin requires one of those files during WordPress boot, the materialized branch shows WordPress generic critical-error page.

ForkPress should keep the initial clone thin, but it must not leave the branch unusable when the missing file is discoverable and can be fetched narrowly.

Implementation

Added bundled scripts/cow/wp_boot_smoke.php, which boots the materialized branch through index.php with the preview host and branch context. branch_remote_site() runs that smoke test immediately after branch materialization.

The CLI now uses smoke-test failures as a repair signal:

1. Parse the PHP failure for a quoted path under the materialized branch root.
2. Accept only safe relative paths under managed excluded prefixes, currently including wp-content/uploads/, cache/backup/upgrade-style directories, and not arbitrary plugin/theme code.
3. Run rsync -azR remote:/path/./<relative-file> <cache> to fetch exactly that file.
4. Recreate the branch from the healed cache and smoke-test again, up to a small retry limit.

run_php_script() now includes filtered stdout/stderr in the returned error on failure, so callers can act on the PHP diagnostic instead of only seeing “script exited.”

Testing instructions

php -l scripts/cow/wp_boot_smoke.php
php tests/cow/wp_boot_smoke.php
make test-cow-branch-boot-smoke
FORKPRESS_RUNTIME_BUNDLE=/dev/null cargo test -p forkpress-runtime
FORKPRESS_RUNTIME_BUNDLE=/dev/null cargo test -p forkpress-storage remote_branch_preview_host
FORKPRESS_RUNTIME_BUNDLE=/dev/null cargo test -p forkpress-cli remote_clone

Local SSH repro also passed: a real ForkPress-backed remote source booted with an active plugin requiring wp-content/uploads/forkpress-required/bootstrap.php; default thin remote clone --branch skipped uploads, fetched that one missing file after the smoke failure, recreated the branch, and then booted http://thin-branch.wp.localhost:18080/.

[adamziel]

Local integration smoke added to the PR evidence. Docker is not installed in this runner, so I exercised the same remote-clone path with localhost SSH plus a temporary local MariaDB/WordPress site.

What passed:

mysql:     imported 12 tables, 131 rows into wp-content/database/.ht.sqlite
preview:   booted http://production-main.wp.localhost:18080/
forkpress: remote cache 'local-healthy' branched to 'production-main'\n```\n\nThen I activated a deliberately fatal remote plugin and reran `remote clone --branch` against the same SSH/MySQL remote. The new guard failed before reporting branch success:\n\n```text\nforkpress: branch preview PHP exception while booting http://production-broken.wp.localhost:18080/: Call to undefined function forkpress_remote_clone_missing_function_for_smoke() ...\nforkpress: remote cache 'local-broken' was branched to 'production-broken', but the branch homepage did not boot. The branch was left in place for inspection; retry with --force after fixing the reported error.\n```\n\nThat test used real `rsync` over SSH, the remote `php`/`mysqli` MySQL exporter, the SQLite importer, branch materialization, and the new homepage boot smoke.