00c12dac61
A same-day version-floor bump (0.20 runtime contract) left every install with an older cua-driver hard-failing on all computer_use calls: the start() gate fails closed, while the `hermes update` refresh defers to the driver's own check-update verb — whose ~20h cache routinely answers "no update available" right after we raise the floor. Hermes knew it required 0.20+ but never acted on that knowledge. Two changes: - tools_config.install_cua_driver(): a contract-failed installed driver is repaired on the upgrade=True path too (previously only upgrade=False). The contract failure itself is the confirmation, so the require_confirmed_update gate and the check-update short-circuit are bypassed for repairs — an indeterminate or stale-cached check can no longer pin users on an unusable driver. - cua_backend.CuaDriverBackend.start(): when the contract gate fails on an installed binary, attempt one automatic repair per process via the standard install path, then re-probe. HERMES_CUA_DRIVER_CMD overrides are never repaired (explicit override is authoritative even when broken) and a missing binary still just reports the install hint. A failing installer can't loop: the second start() surfaces the original error. Tests: contract-repair coverage in test_computer_use.py (auto-repair success, failed repair surfaces the original error, once-per-process guard, override never repaired, missing binary never repaired) and test_install_cua_driver.py (incompatible driver repairs despite an indeterminate check-update, check-update not consulted). All new tests verified to fail against the unfixed source (sabotage run).