test(api): generate the pinned OpenAPI digest instead of hand-editing it

[marckong]

Tracking

None. Unblocks #5 and future automated contract syncs.

Why

spec/volcano_generation_spec.rb hardcoded the SHA-256 of openapi/openapi.yaml. The Volcano sync (volcano-hosting/scripts/ci/prepare-openapi-consumer-container.sh) copies the contract and runs bin/generate-openapi and bin/check-openapi, but nothing updated the pin, so #5 fails Ruby 3.3/3.4 tests and the Quality Gate. A hand-pushed bump to the sync branch was overwritten within seconds when the bot force-rebuilt it.

Summary

• bin/generate-openapi writes the contract digest to openapi/openapi.yaml.sha256 when generating the committed output (not for the temporary check output).
• The spec reads that file instead of a literal.
• bin/check-openapi also fails if the file is stale, so changing the contract without regenerating still fails CI.
• CONTRIBUTING.md notes the new file. Initial value is the current main digest (d8d8f53d…), so this PR changes no behavior by itself.

Tradeoff: the digest is no longer an independent hand-edit that forces a person to acknowledge a contract change. The diff of the vendored spec in the sync PR and its AI/human review remain that gate.

Verification

• Not run: full generation and the spec need Java and Ruby 3.3+, which this machine lacks (Ruby 2.6, no JRE). CI on this PR is the verification.
• bash -n passes for both scripts, and the digest in the new file matches openapi/openapi.yaml on main.
• Once merged, the next sync will write openapi/openapi.yaml.sha256 itself; chore(api): sync OpenAPI contract #5 would need to be rebuilt by the bot to pick it up.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}