First, "thank you" then some ideas :-)

Daniel, we meet again, one more time on security topics 😍
So yes, first, a big thank you for putting this one out!

Some general observations and thoughts:
1. Would you consider a version of this GitHub Action as an npm package that will take a package name + version (or tag) and return the outputs per the way this action works? The idea being that it can be run programmatically (and not requiring a lockfile). If so, I'd happily use this for npq instead of sigstore dependency (which adds quite a bit of nested deps tree). You can see the implementation at https://github.com/lirantal/npq/blob/main/lib/helpers/npmRegistry.js and https://github.com/lirantal/npq/blob/main/lib/marshalls/provenance.marshall.js
2. The verification only checks one version back?
3. Continuing from (2), if an attacker publishes 2 malicious versions then basically the "before" is without attestation and the new is also without attestation and potentially bypasses the provenance check if I understood correctly on how you compare here.

Review the provenance action's current verification flow, then compare its behavior with lib/helpers/npmRegistry.js and lib/marshalls/provenance.marshall.js in npq. Clarify whether a package API is in scope and determine how the one-version and two-malicious-version cases should be handled; done means the intended behavior and testable acceptance criteria are agreed.

Written by the indexing model from the issue text.