Enforce public Rustdoc before release

[bordumb]

What changed

• publicly re-export CommitmentError and OutputError from auths-bounded-policy
• run the exact release Rustdoc gate in ordinary authoritative CI on every PR
• reuse that authoritative gate from release-check instead of documenting the workspace twice
• replace both Docker-based cargo-deny-action uses with a locked post-checkout cargo-deny 0.20.2 installation and direct cargo deny check
• refresh the production translation closure and semantic-freeze identities

Root cause and evidence

Preparation run 30814181722 reached cargo xtask release-check and failed because public bounded-policy constructors linked to error types that were not reachable from the public crate root. The previous lifecycle fix addressed only the first crate reported by the fail-fast documentation build, allowing the same class in the next crate to remain hidden until preparation reran.

This PR closes the class repository-wide and moves detection before merge.

The first PR run also exposed an independent CI infrastructure defect: GitHub's hidden pre-job build for the Docker-based cargo-deny action timed out against Docker Hub before checkout. Checkout was therefore skipped, and the always() telemetry step produced a secondary missing-local-action error. Both normal CI and release preparation now avoid that hidden Docker build entirely.

Verification

• RUSTDOCFLAGS='-D warnings' cargo doc --workspace --all-features --no-deps passed
• the command documented auths plus 93 other workspace packages successfully
• cargo fmt --all --check passed
• formal source closure and semantic freeze were regenerated with explicit new identities
• GitHub CI on this PR remains the authoritative full verification

Affected claims

• every public Rustdoc intra-doc link resolves without private-item access
• public constructor error types are nameable by downstream users
• the release documentation gate is enforced before merge
• release preparation does not duplicate a gate already run by authoritative CI
• dependency enforcement runs after checkout and no longer depends on Docker Hub or a hidden pre-job container build

Exclusions

• no policy evaluation, lifecycle transition, wire, receipt, or provider behavior changes
• no RC tag or GitHub release creation
• no crates.io, npm, or PyPI publication
• no SLSA Build Level 3 claim or promotion authorization

Remaining gates

• merge only after authoritative GitHub CI succeeds
• require a green push-to-main run on the exact merged commit
• restart both isolated preparations from that new exact main SHA
• require successful byte comparison and staging before preparation is complete
• keep promotion blocked pending independent SLSA assessment and exact owner authorization