Krikri::PluginHelpers::RpmSpecProbe

Batched "what does the host already know about these specs?" probing for the RPM-family package plugins (dnf.cr, yum.cr via RpmPackage, and package.cr's own dnf backend).

Ansible's dnf module hands a whole name: list to ONE depsolve, so its cost is flat in the number of names. This engine answered "installed? / available in the repos? / provided by something?" per name, each answer a separate process spawn: a perl(Foo::Bar) capability list therefore paid ~2.7s per entry (one dnf4 CLI startup each - dnf4 only answers the repo-row question through the CLI, there is no cheap alternative) and a 75-name list took minutes (issue #904). Both questions the RPM database can answer itself are collected here in a SINGLE round trip for the whole list, so only the repo-row question needs one dnf invocation per list rather than one per name.

Specs rpm can answer ambiguously (shell globs would expand to thousands of rows, and a newline would break the marker framing) are rejected by #rpm_probe_batchable? so their callers keep the old per-spec path for them.