ci: fix the cargo-public-api double install

[abnobdoss]

Which issue does this PR close?

• None. CI maintenance for the Public API job.

What changes are included in this PR?

The job installs cargo-public-api twice per run. taiki-e/install-action has no prebuilt binary for it, so that step falls back to cargo-binstall and compiles the latest release from source (currently v0.52.0, ~76s). make check-public-api then compiles the pinned v0.51.0 from source again (~72s) because the installed version doesn't match the pin. And since the binary on disk never matches the pin at cache-save time, rust-cache never shortcuts either install.

This deletes the install-action step. The Makefile's cargo install --locked cargo-public-api@0.51.0 becomes the only install; on warm runs rust-cache restores the pinned binary and the install is a no-op. 0.51.0 is the version the checked-in public-api.txt files were generated with, so the check itself is unchanged.

The Makefile also stops computing PUBLIC_API_CRATES with $(shell cargo metadata ...) at parse time, which made every make invocation pay a cargo metadata call. The list is now evaluated inside the two recipes that use it, with identical command and output.

Warm Public API job time on a fork: 4:03 to 1:36.

Are these changes tested?

• Verified on a fork: warm runs skip the install and run the same checks.
• make check-public-api and make generate-public-api expand to the same commands as before.

[blackmwk]

Thanks @abnobdoss for this fix!