Harden Odoo target replacement verification

[cbusillo]

Summary

• retry Odoo target replacement health/canonical/logo verification for transient startup 404s
• make the target replacement workflow fail when the accepted driver result reports failed deploy/post-deploy status
• add regression coverage for the retry helper

Context

This came out of cbusillo/odoo-devkit#34 live verification. Target replacement was accepted by Launchplane but returned deploy_status: fail after a transient /web/health 404, while the GitHub Actions job still appeared successful. That prevented inventory from advancing to the newer CM artifact, so stable bootstrap kept using stale artifact artifact-cm-56978ff75c57c6a0 from source f358c2d.

Tests

• uv run python -m unittest tests.test_odoo_stable_target_replacement
• uv run --extra dev ruff check --diff control_plane/workflows/odoo_stable_target_replacement.py tests/test_odoo_stable_target_replacement.py
• uv run --extra dev ruff check control_plane/workflows/odoo_stable_target_replacement.py tests/test_odoo_stable_target_replacement.py
• ruby -e 'require "yaml"; data = YAML.load_file(".github/workflows/odoo-target-replacement-apply.yml"); abort("bad name") unless data["name"] == "Odoo Target Replacement Apply"; puts "yaml ok"'

Notes

• actionlint .github/workflows/odoo-target-replacement-apply.yml still reports the existing workflow-dispatch input-count warning for this workflow.