Consolidate duplicated publish jobs in publish-crates.yml

Follow-up from review of #92 (comment).

.github/workflows/publish-crates.yml has six near-identical publish-* jobs, one per crate. Each repeats the same checkout / toolchain / cargo publish steps, differing only in the crate path, the determine-targets output it gates on, and its needs: chain.

The separate jobs are intentional — a partial release failure is visible per crate and individually re-runnable, and needs: encodes publish order (optipy → rigetti-pyo3 → pyo3-tracing-subscriber; pyo3-opentelemetry-macros → pyo3-opentelemetry). Any consolidation must preserve both properties.

Options worth exploring:

• Extract the shared steps into a local composite action under .github/actions/, keeping the six jobs as thin wrappers. Lowest risk, removes most of the duplication.
• A matrix job with a dependency-ordered set of stages (one matrix per topological level). Fewer job definitions, but the ordering becomes less explicit.

Not blocking; purely a maintainability cleanup.

Start with .github/workflows/publish-crates.yml and inspect the six publish-* jobs, their crate paths, determine-targets gates, and needs chains. Compare the composite-action and staged-matrix options described in the issue, then verify that each crate remains independently visible and re-runnable, partial failures remain clear, and publish ordering is preserved.