Please make the exact crate dependency set of published prebuilt binaries reproducible (Cargo.lock / cargo-auditable / bundled third-party notices)

Hi, thanks for maintaining keyring-node!

We ship `@napi-rs/keyring` (specifically the `-darwin-arm64` prebuilt) inside a desktop
application, and as part of open-source license compliance we need to list the copyright
and license notices of all Rust crates statically linked into the published `.node` binary.

Currently this is hard to do accurately, because:

- The repository does not commit `Cargo.lock` (and CI does not build with `--locked`),
so the exact transitive crate versions used for a given published binary are not
recorded anywhere.
- The npm packages have provenance attestations (thanks for that!), which pins the source
commit — but regenerating a lockfile from that commit today resolves different versions
than the ones actually linked (e.g. the published `keyring-darwin-arm64@1.3.0` binary
embeds `napi-3.8.6` / `anyhow-1.0.102` / `apple-native-keyring-store-1.0.0`, while a
fresh resolution picks newer versions of all three).
- The prebuilt npm package contains only the project's own LICENSE, not the third-party
crate notices.

We completely understand if you prefer to keep `Cargo.lock` out of version control — that
has long been common practice for library crates, and we're not questioning it. Our ask is
only about the published prebuilt binaries: any record of the dependency set that went into
them (in whatever form is most convenient for you) would be a big help for downstream
license compliance. (For reference, Cargo's defaults changed in August 2023 —
rust-lang/cargo#12382 — to check in `Cargo.lock` by default; but every option below works
equally well for us, and the last one avoids committing a lockfile entirely.)

Would you consider any of the following? Any one of them would make downstream compliance
much more reliable:

1. **Commit `Cargo.lock`** and build releases with `--locked` (also improves build
reproducibility), or
2. **Build release binaries with [`cargo auditable`](https://github.com/rust-secure-code/cargo-auditable)**,
which embeds the exact dependency list into the binary at negligible size cost
(this also enables `cargo audit bin` for security scanning), or
3. **Bundle a generated third-party license file** (e.g. via
[`cargo-about`](https://github.com/EmbarkStudios/cargo-about)) in the prebuilt npm packages, or
4. If you'd rather not commit a lockfile at all: generate one in CI, build with `--locked`,
and **attach that `Cargo.lock` as a release/CI artifact** — that equally records what shipped.

Happy to provide more details about our use case if helpful. Thanks!

Start by reviewing the CI release build, Cargo.lock handling, and the process that creates the prebuilt npm packages. Compare the proposed cargo-auditable, bundled license file, committed lockfile, and CI artifact approaches with the maintainers. Done means each published binary has a reliable record of its exact Rust dependencies and the required third-party notices are available to downstream users.

Written by the indexing model from the issue text.