fix: detect stale Kimaki dispatch helpers

[chubes4]

Summary

• Require non-root Kimaki helper health checks to match the current wrapper, target, and sudoers templates and prove both www-data and the adopted service user can traverse the registered wrapper path.
• Emit a machine-readable root_repair_required result plus an exact shell-safe root repair command when non-root cannot inspect, validate, or repair root-owned artifacts.
• Rewrite and post-validate all helper artifacts during root upgrades, including current caller grants, and add a dedicated CI regression for repeated non-root upgrades over pre-Fix Kimaki dispatch sudoers for service user #243 state.

Root cause and production timeline

Production helper artifacts were installed as root at 2026-06-27 01:24 UTC. PR #243, which added the required www-data -> SERVICE_USER sudoers grant, merged later at 2026-06-27 01:56 UTC.

The non-root upgrade fast path checked only that the adopted service user could invoke the target directly. That path bypassed the registered wrapper and never inspected the root-owned sudoers file, so the pre-#243 service-user-only grant was repeatedly certified as healthy while scheduled WordPress dispatch from www-data continued failing.

Why #240 and #243 did not stick

#240 established the wrapper-based dispatch path, and #243 corrected the generated sudoers template to include www-data. Neither changed the non-root upgrade health oracle: an already-installed target that worked for the service user still caused an early return before current wrapper, target, or sudoers content was compared. Because non-root upgrades could not rewrite the root-owned files, the corrected #243 template never reached this host.

Ownership boundary

wp-coding-agents owns generation, installation, upgrade health, and repair instructions for the Kimaki wrapper, target, and sudoers artifacts. Homeboy may invoke an upgrade, coordinate a deployment, or consume its output, but it does not own or infer the health of these wp-coding-agents installation artifacts. This PR keeps the repair signal and validation in the owning bridge installer rather than adding Homeboy-specific behavior.

Behavior

Before:

• SERVICE_USER -> target --version was treated as complete helper health.
• Stale root-owned sudoers content could survive every non-root upgrade.
• Scheduled www-data -> wrapper -> SERVICE_USER execution was not tested.

After:

• Non-root health requires exact generated-content matches for wrapper, target, and sudoers plus successful wrapper execution as both www-data and the adopted service user.
• If privilege prevents inspection or either caller proof, output includes {"status":"root_repair_required",...} and an exact sudo -- .../upgrade.sh --kimaki-only --wp-path ... --kimaki-unit ... repair command; the final summary repeats the required action.
• Root upgrades rewrite all three artifacts, validate sudoers syntax when visudo is available, compare installed bytes with generated content, and execute the wrapper through both caller identities.
• Local mode, root service identities, explicit identity flags, and per-instance helper suffixes retain their existing branches.

Tests

• Added tests/kimaki-dispatch-helper-health.sh and a dedicated CI job.
• Covers pre-Fix Kimaki dispatch sudoers for service user #243 service-user-only sudoers state across repeated non-root upgrades and proves it is never logged as healthy.
• Covers structured repair output and the exact repair command.
• Covers www-data and service-user grants, caller validation, and deduplication when the service user is www-data.
• Covers root rewrite against current generated content.
• Passed all bounded shell workflow tests, all tracked shell syntax checks, git diff --check, and focused shellcheck on modified scripts.

Remaining privilege limitations

A normal service user commonly cannot read /etc/sudoers.d or impersonate www-data; that is now reported as root repair required rather than guessed healthy. The root repair remains an explicit operator action. This PR does not merge, release, deploy, restart Kimaki, or verify production cron dispatch; production verification follows the eventual authorized merge/release/deploy.

Closes #304