feat: integrate CI signing setup into auths init

[bordumb]

Summary

Move the CI release signing setup (currently in crates/xtask/src/ci_setup.rs, invoked via cargo xt ci-setup) into the main auths init flow as an optional step, and expose it as a standalone auths init --ci command for later use.

Motivation

• ci-setup is currently buried in xtask — users who install via Homebrew or cargo install can't access it
• CI signing is the primary use case for auths, so it should be discoverable during init
• Setting up a new repo for CI signing requires knowing about cargo xt ci-setup, which is undocumented outside contributing docs

Proposed UX

During auths init (interactive prompt)

Identity created successfully.

Would you like to set up CI release signing? (y/N)

If yes, walks through CI device key creation, identity bundling, and platform secret setup.

Standalone: auths init --ci

For users who skipped during init or need to add CI signing to another repo later. Assumes an existing identity (skips identity creation, reuses ~/.auths).

Standalone: auths ci add-repo

For adding secrets to additional repos using an already-created CI device key. No key generation — just sets platform secrets.

Design questions to resolve

1. Platform detection

The current implementation assumes GitHub (gh CLI, GitHub secrets). We need to support at minimum:

• GitHub — gh secret set
• GitLab — glab variable set or GitLab API
• Self-hosted / other — manual export (print values for user to copy)

Options:

• Auto-detect from git remote URL (github.com vs gitlab.com)
• Explicit flag: auths init --ci --platform github
• Interactive prompt: "Where does your CI run? [GitHub / GitLab / Other]"
• Start with GitHub + manual fallback, add GitLab later

2. Identity assumption with --ci

auths init --ci (without a fresh init) should:

• Verify an identity exists in ~/.auths
• Reuse it — no re-init
• Error clearly if no identity found: "No identity found. Run auths init first."

3. Multiple repos, same identity

The CI device key and identity bundle are per-identity, not per-repo. The per-repo part is just setting the secrets. The flow should be:

• First time: create CI device key + set secrets on repo
• Additional repos: reuse existing CI device key + set secrets on new repo (auths ci add-repo)

4. Secret naming convention

Current secrets: AUTHS_CI_PASSPHRASE, AUTHS_CI_KEYCHAIN, AUTHS_CI_IDENTITY_BUNDLE. These should remain the same across platforms for consistency in workflow files.

Implementation plan

1. SDK workflow (CiSetupWorkflow): Extract domain logic from ci_setup.rs — key generation, device linking, identity bundling, keychain export. Returns the 3 secret values. No I/O to GitHub/GitLab.
2. Platform adapters: Trait for setting CI secrets, with implementations for GitHub (gh), GitLab (glab), and manual (print to stdout).
3. CLI integration: Add --ci flag to auths init. Add auths ci add-repo --repo owner/repo command.
4. Deprecate xtask ci-setup: Once CLI command exists, remove or redirect cargo xt ci-setup.

References

• Current implementation: crates/xtask/src/ci_setup.rs
• Justfile recipe: just ci-setup
• Docs: docs/contributing/release-process.md ("One-time CI signing setup")