wfctl plugin install reports upgraded plugin but leaves stale executable

[intel352]

Context

While bumping workflow-compute from workflow-plugin-digitalocean v1.0.6 to v1.0.8, local wfctl plugin install printed:

Installed workflow-plugin-digitalocean v1.0.8 to data/plugins/digitalocean

but go version -m data/plugins/digitalocean/digitalocean still showed the executable was built from github.com/GoCodeAlone/workflow-plugin-digitalocean v1.0.6+dirty with internal.Version=1.0.6. The repo verifier correctly failed.

Expected

wfctl plugin install should leave the plugin directory containing only the requested/resolved version, or fail loudly if it cannot replace the executable.

Why it matters

A stale plugin binary can pass through install output and then make infra dry-runs/applies use an older provider implementation than the lockfile declares. This already bit workflow-compute during the staging DO route recovery path.

Suggested invariants

• Plugin install prunes or atomically replaces the target plugin directory before unpacking a new version.
• After install, wfctl verifies executable metadata/manifest version matches the requested lock entry.
• If replacement is impossible, install fails; it must not print success.

Related

workflow-compute has local invariant V89 for stale plugin executables, but the durable fix belongs in wfctl plugin installation semantics.