release: bootstrap the three crate names and trusted publishing

## Outcome

Secure and publish the three durable names in the first isolated SDK-Rust
release train:

- `identus-derive`
- `identus-core`
- `identus-crypto`

This issue no longer reserves speculative future crates. New package names
must follow their own approved architecture and release slice.

## First-publish constraint

crates.io trusted publishing cannot create a crate. Each package therefore
needs one tightly controlled bootstrap publication before its GitHub trusted
publisher can be configured. The bootstrap is a human release operation, not
agent authority.

## Tasks

- [ ] Confirm all three names remain available immediately before the release
window.
- [ ] Assign one Hyperledger/Identus release manager and one independent
approving maintainer to the exact candidate receipt.
- [ ] Create a short-lived, least-privileged crates.io token for only the
initial publication; never store it in the repository or ordinary CI.
- [ ] Publish the three reviewed `0.1.0-rc.1` archives in dependency order:
`identus-derive`, `identus-core`, then `identus-crypto`.
- [ ] Configure crates.io trusted publishers for this repository and release
workflow immediately after each first publication.
- [ ] Revoke the bootstrap token and prove the next dry-run/release path uses
only short-lived OIDC credentials.
- [ ] Record owners, recovery/yank responsibilities, immutable checksums, and
the release receipt in the repository release documentation.

## Acceptance

- The three names resolve to the reviewed Hyperledger Identus packages with
repository, license, documentation, and ownership metadata.
- The bootstrap token is revoked and no long-lived crates.io credential is
present in GitHub Actions or repository settings.
- Trusted publishing is configured for subsequent versions.
- No placeholder or speculative crate is published.

## Authority boundary

This issue is a blocker record, not publication authorization. Tagging,
publishing, `main` promotion, and crates.io settings changes require the exact
M3 candidate receipt plus explicit human release authority under #326.

Start by reading the M3 candidate receipt and the authority requirements under #326, then review the release workflow and repository release documentation. Verify the three crate names, dependency-order archives, trusted publisher configuration, token revocation, OIDC-only path, ownership records, and immutable checksums. Done means all acceptance checks pass without publishing speculative crates.

Written by the indexing model from the issue text.