Report which locked gems have no variant for the current platform

[Mousa96]

Problem

When a lockfile lists the current platform under PLATFORMS but one of its locked gems has no
variant for that platform, Definition#materialize re-resolves the incomplete gems against the
remote source. That auto-healing is deliberate, and it is announced with a debug message:

The lockfile does not have all gems needed for the current platform though, Bundler will still re-resolve dependencies

The message doesn't say which platform is current, or which gems are incomplete. Against a public
source the re-resolve succeeds and nobody notices. Against a private source the process has no
credentials for, it fails, and the default output is just Authentication is required for <host>,
which points the reader at credentials rather than at the lockfile. Re-running with --verbose is
the natural next step, and today it only gets you halfway: you learn that some locked gem has no
variant for this platform, but not which one.

Our lockfile listed both arm64-darwin and x86_64-linux under PLATFORMS, and out of roughly
500 gems exactly one — commonmarker — was locked only as commonmarker (2.9.0-arm64-darwin).
CI runs on x86_64-linux, so that single missing variant was enough to send Bundler to the
network, and with 500 candidates and no name the verbose output didn't say where to look.

Before

Found no changes, using resolution from the lockfile
The lockfile does not have all gems needed for the current platform though, Bundler will still re-resolve dependencies
Resolving dependencies...

After

Found no changes, using resolution from the lockfile
The lockfile does not have all gems needed for the current platform (x86_64-linux) though, Bundler will still re-resolve dependencies. The following locked gems have no variant for it: commonmarker-2.9.0-arm64-darwin
Resolving dependencies...

With the gem named, the reader can confirm the diagnosis against PLATFORMS in the lockfile and
re-lock that one gem, instead of reproducing the heal in a non-frozen environment on the affected
platform and diffing lockfiles just to learn which gem to look at.

Scope

Message content only. The log level, the placement inside the loop, and the auto-heal behaviour are
unchanged. The two sibling conditions in the same method (partially_missing_specs,
insecurely_materialized_specs) already interpolate full_name, so this only prints what the
method already knows. Kept at debug to match current behaviour — happy to revisit the level
separately if you'd prefer it louder.

The existing spec covering recovery from an incomplete lockfile (spec/runtime/platform_spec.rb)
already ran with --verbose and asserted on this line; it now also asserts the platform and the
incomplete gem, and still asserts that the install heals. The opening clause is byte-identical, so
other assertions on that substring are unaffected.

Related

#9439 improved the message for the adjacent case where the current platform is missing from
PLATFORMS entirely. This covers the case where the platform is listed but a gem's variant for it
is not. #8029 added the insecurely_materialized_specs warning referenced above.