post_create: DB hooks over host TCP run once with no retry — a transient handshake EAGAIN on a loaded host still fails first-run migrations

[ikeikeikeike]

Context

Follow-up (defense-in-depth) from the mysql readiness-race investigation whose root cause is already fixed in #90 / v0.9.29 (dockerReadyCheck no longer answers ready during the mysql:8.4 temporary-server phase). This issue is the secondary hardening item ranked #3 in that handover.

Problem

runPostCreateHooks (internal/cli/create.go:639, called at :178) fires each repository's post_create: line exactly once. For an engine-provider repo whose post_create connects to the DB over host TCP immediately after Up/ReadyCheck returns (e.g. make create-database → make migrate), a single transient failure kills that step with no recovery.

Even with a correct readiness check (post-#90), a heavily-loaded host can still surface a transient ERROR 2013 ... at 'handshake: reading initial communication packet', system error: 35 (EAGAIN) on the very first connection — docker-proxy/mysqld can momentarily fail to complete the handshake under load. Today that transient error is terminal for the affected post_create line.

Proposal

Add a small bounded retry (e.g. 3× with backoff) around each post_create line — or at least around a step that exits non-zero with a connection/handshake-class error — so first-run migrations are resilient to a single transient blip. Scope it narrowly (retry count + backoff as constants or per-engine tunables seeded by the constructor, not package-scope globals).

Notes

• Distinct from docker backend: ES readiness doesn't check cluster health, UpOrReuse doesn't handle a paused container #81 (ES cluster-health readiness) and bough create: engine-provider repo's git worktree add fails (exit 128), then bough writes .env.local + runs post_create into the broken dir and still exits 0 #41 (closed; git-worktree-add-broken-dir path).
• Root-cause fix already shipped: fix(mysql): docker ReadyCheck no longer answers ready during the mysql:8.4 temporary-server phase #90 / v0.9.29. This is purely additional robustness.