Summary

Migrate `release.yml` and `publish-retry.yml` from `cargo xtask publish` to shipper. Both v0.7.0 publish attempts via the hand-maintained `PUBLISH_CRATES` list have failed — the user built shipper for exactly this class of bug.

Why

Attempt 1 (tag at #562 merge): `uselesskey-core-seed` packaged before `uselesskey-core` because PUBLISH_CRATES listed compat shims before owner crates. Fixed in #565.

Attempt 2 (tag at #565 merge): `uselesskey-core` packaged but failed because its dev-dep `uselesskey-test-support` (workspace entry has `version = "0.7.0"`) is not in PUBLISH_CRATES at all.

Both failures are the same class of bug: a hand-maintained linear list of crates that silently drifts out of sync with cargo metadata when deps move. Shipper computes the publish DAG directly from cargo metadata, reconciles against registry truth, retries transient errors, and persists state under `.shipper/` so interrupted runs can resume.

Changes

Both workflows now run:

```yaml

• name: Install shipper
  run: cargo install shipper --locked --version "0.3.0-rc.2"
• name: Plan
  run: |
  mkdir -p .shipper
  shipper plan --format json | tee .shipper/plan.txt
• name: Upload plan state
  uses: actions/upload-artifact@v7
  with: { name: shipper-state-plan, path: .shipper/, include-hidden-files: true, retention-days: 30 }
• name: Preflight
  run: shipper preflight --policy safe
• name: Publish
  run: shipper publish --policy safe --readiness-method both --max-attempts 12 --max-delay 15m
• name: Upload final state
  if: always()
  uses: actions/upload-artifact@v7
  with: { name: shipper-state-final, path: .shipper/, include-hidden-files: true, retention-days: 90 }
  ```

`publish-retry.yml` keeps its workflow_dispatch inputs (`tag`, `resume_from`, `dry_run`):

• Empty `resume_from` → `shipper publish` (reconciles against registry)
• Non-empty `resume_from` → `shipper resume --resume-from `
• `dry_run: true` → `shipper plan --format text` preview, no publish

Token still comes from `secrets.CARGO_REGISTRY_TOKEN`. OIDC via `crates-io-auth-action` is a separate follow-up.

Recovery plan for in-flight v0.7.0

Already at 0.7.0 on crates.io: `uselesskey-core-hmac-spec`, `uselesskey-jwk`, `uselesskey-core-jwk` (3 of 53). All others still at 0.6.0.

After merge:

1. `gh workflow run publish-retry.yml -f tag=v0.7.0 -f dry_run=true` — preview shipper's plan
2. Verify the 3 already-published crates show as skipped/satisfied
3. `gh workflow run publish-retry.yml -f tag=v0.7.0` — execute live
4. Shipper publishes the remaining ~50 crates in DAG order

Follow-up work

• Adopt `rust-lang/crates-io-auth-action` OIDC token flow.
• Drop hand-maintained `PUBLISH_CRATES` from `xtask/src/main.rs` once shipper handles all paths.
• Originally planned: topo-sort verification in publish-check (no longer needed if shipper owns the publish lane).

Test plan

• CI green on this PR (YAML lint, etc.)
• Dry-run shipper plan against v0.7.0 shows correct DAG and skips the 3 already-published crates
• Live shipper run publishes the remaining 50 crates