Investigate whether Kani is being cached correctly in CI

Currently, in our "generate cache" job, we install Kani like so:

https://github.com/google/zerocopy/blob/04d825fd7d46cafce2acd28b11c655648fb252a6/.github/workflows/ci.yml#L506

However, this is how we use Kani:

https://github.com/google/zerocopy/blob/04d825fd7d46cafce2acd28b11c655648fb252a6/.github/workflows/ci.yml#L394-L414

Are we actually benefitting from caching the Kani installation? Are we guaranteed that these will be the same version? It looks like [we originally used `cargo` directly](https://github.com/google/zerocopy/commit/fdbb893350e7496e823a1704450fbe843f6a250c) (rather than the Kani GitHub Action), and so this may just be a case of bit rot.

It's also possible that the Kani GitHub Action uses `cargo install` under the hood, so we might still be benefitting. If this is the case, then we could try to be fancy and do one of the following:
- Also encode the pinned Kani version when we `cargo install` in the "generate cache" job, and have the [Kani roller](https://github.com/google/zerocopy/blob/04d825fd7d46cafce2acd28b11c655648fb252a6/.github/workflows/roll-pinned-toolchain-versions.yml#L124-L156) update that version as well
- Have the "generate cache" job introspect `ci.yml` to extract the pinned Kani version and use it for `cargo install`

Both of these are probably overkill. It might be worth adding a comment to this effect, but since we roll Kani nightly, and since Kani rarely publishes new versions, it will almost always be the case that we are pinned to the latest version, and so `cargo install` and the Kani GitHub Action will use the same version. Since the cache is best-effort anyway, it's probably the best tradeoff to just avoid the complexity of either of those solutions.