wfctl plugin conformance artifact mode should discover release binary names

[intel352]

Problem

wfctl plugin conformance --artifact currently expects the executable inside the extracted archive to be named after normalizePluginName(manifest.Name). That works for some fixtures, but mature GoReleaser plugins can ship binaries named after the full project, for example workflow-plugin-digitalocean.

Observed while wiring workflow-plugin-digitalocean conformance CI:

• source mode passes with --build-package ./cmd/plugin
• artifact mode against a release-shaped tarball fails with only error: exit status 1
• no conformance-evidence.json is written because the failure occurs before useful evidence is returned

Desired behavior

• Artifact mode should discover a valid executable from the extracted archive when the manifest name, normalized install name, and packaged binary name differ.
• Failure evidence should still be emitted when the manifest is loadable but plugin launch/conformance fails.
• Diagnostics should name the executable candidates considered and the selected path.

Why

Plugin compatibility evidence is strongest when it is bound to release artifacts. Until artifact mode handles real GoReleaser archive shapes, plugin CI must use source-mode conformance for trusted pushes.

Related

• workflow PR Fix plugin conformance source build packages #630 added source --build-package support.
• workflow PR Accept engine pseudo-versions in plugin evidence #631 allows conformance evidence to record post-release engine pseudo-versions truthfully.

[intel352]

Additional acceptance from antagonistic review: executable discovery must not only find a file with an executable bit. It must prove the selected candidate performs the Workflow go-plugin handshake and registers the expected typed-IaC services. A semantically wrong executable, for example a CLI/info binary in a plugin archive, must fail with diagnostics that list candidates and the handshake/service-registration failure.