release: publish approved v0.5.1 crates.io surface

[DecisionNerd]

Objective

Authorize the existing release workflow to publish the approved v0.5.1 crates.io surface in Cargo dependency order, then record the public result.

Done when

• ci: keep v0.5.1 publication automation small and resumable #288 has made the candidate eligible and the release workflow verifies each required crate as it proceeds.
• The public crate set identifies the expected v0.5.1 artifacts.
• The result is linked once from release: ship GraphForge v0.5.1 with fast-fail recovery #192's final release record.

Non-goals

• Changing Rust behavior, adding binding fallbacks, or creating a separate release test matrix.
• Publishing Python/Node implementation crates.

[DecisionNerd]

Human blocker (crates.io names)

gf-core on crates.io is owned by cryptopatrick (Grammatical Framework runtime), not GraphForge. gf-cli is also a foreign crate (justinwangx).

Automation in https://github.com/CurateLabs/graphforge-legecy/pull/2820:

• scripts/ci/crate-publish-plan.py computes library publish order (gf-core … gf-api) and fails closed on this conflict + missing path version= deps required for cargo publish.
• publish.yaml records the plan as a release artifact; it does not run real cargo publish yet.

Required maintainer disposition before #196 can close: rename GraphForge crates (or otherwise choose non-conflicting crates.io names), land path+version dependency metadata, and confirm CARGO_REGISTRY_TOKEN / ownership. Do not partial-publish under conflicting names.