--prefer-local ignores gems with native extension

$ gem list | grep bundler
bundler (2.6.9)

$ mkdir test-prefer-local

$ cd test-prefer-local/

$ cat <<EOF > Gemfile
source "https://rubygems.org"

gem "sqlite3", ">= 2.1"
EOF

$ cat Gemfile
source "https://rubygems.org"

gem "sqlite3", ">= 2.1"

$ gem list | grep sqlite
sqlite3 (2.5.0)

$ bundle install --prefer-local
Fetching gem metadata from https://rubygems.org/.....
Resolving dependencies...
Fetching sqlite3 2.5.0 (x86_64-linux-gnu)
Installing sqlite3 2.5.0 (x86_64-linux-gnu)
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

I suspect this has something to do with the architecture, but not sure what. IMHO Bundler should not bother if sqlite3 is available.

OTOH, maybe the Fedora packages (which is the way how the sqlite3 was installed) should be built somehow differently to include some architecture?

But I think Fedora does not do anything different than $ gem install sqlite3 --platform ruby which is valid way of installation of sqlite3 if somebody wants to build the binary extension themselves.

Reproduce the behavior with the shown Gemfile and bundle install --prefer-local, using a locally installed sqlite3 gem with a native extension. Trace Bundler's local-gem and platform selection behavior, then add a regression test demonstrating that the compatible local installation is reused; done means the command no longer fetches and reinstalls that gem.