Binstub with bundle path configured loads wrong version of Bundler

On the latest version of bundler (2.4.18), but I think this applies to all versions, we noticed a bug(?) wherein if you have path configured, a binstub (using require "bundler/setup") boots into the wrong version of Bundler. More specifically, it just uses your system bundler instead of the higher versioned bundler installed (into say, vendor/bundle) and specified by your Gemfile.lock.

We noticed this problem in our Docker image where Ruby 3.2.2 comes with Bundler 2.4.10. We install gems in our docker image to vendor/bundle. If you run bin/rails (or any binstub) and puts Bundler::VERSION inside the process, you'll get 2.4.10 instead of 2.4.18.

This is easily reproducible locally:

1. bundle install --path vendor/bundle
2. gem uninstall bundler (this is to uninstall the higher version of bundler from your system gems. It should be installed into vendor/bundle already).
3. bin/rails runner "puts Bundler::VERSION"

I thought that this was by design since I don't even see how we would load Bundler (whichever one is available), then realize that we've installed gems into a custom path, then switch over to the right version of bundler all within the same process. But then I saw @indirect's blog post: Never bundle exec again and thought, maybe this is an oversight.

Reproduce the issue with bundle install --path vendor/bundle, removal of the higher system Bundler, and bin/rails runner "puts Bundler::VERSION". Start by tracing how the binstub's require "bundler/setup" selects Bundler when gems are installed under vendor/bundle; done means the binstub loads the version specified by Gemfile.lock rather than the system version.