Add trusted Bundler credential helpers

[yokonao]

What was the end-user or developer problem that led to this PR?

Credential helpers avoid storing long-lived registry credentials, but the implementation in #8501 allowed commands from .bundle/config to run during bundle install. A malicious cloned repository could therefore execute arbitrary commands.

What is your fix for the problem, implemented in this PR?

This keeps host-specific credential helpers while requiring explicit user trust. Bundler records the host, resolved absolute path, and SHA-256 in the user's Bundler home, then verifies all three before executing the helper without a shell.

Untrusted, changed, invalid, empty, or failed helpers fall back to existing credential settings.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[hsbt]

Thank you for working on this, but I do not plan to add a credential helper protocol to Bundler core.

#9671 made the credential store pluggable exactly so this kind of integration can live outside core. A helper becomes a small gem that registers a backend via Gem::CredentialStore.register_backend, runs its command lazily in get, and delegates hosts it does not handle to Gem::CredentialStore.default_backend. Installing that gem is the explicit trust decision, so the trust file, digest pinning, and the new bundle credential subcommand become unnecessary, and none of that verification machinery has to be maintained in core.

I would be happy to see the CodeArtifact use case shipped as such a backend gem, and I will take API feedback on the backend interface in #9671.

Closing this one.