No supported install path for consumers without per-deployment GitHub deploy-key enrollment on this repo

[k9ert]

Problem

argit is a private GitHub repository. The currently-documented install path (from argit/install.sh and argit/README.md) is:

uv tool install "git+https://github.com/blinkbitcoin/argit@${ARGIT_TAG}"
# or
pipx install "git+https://github.com/blinkbitcoin/argit@${ARGIT_TAG}"

Both routes require credentials that grant access to a private GitHub repo. The only available auth mechanisms are:

1. A GitHub Personal Access Token (PAT) embedded in the URL or via Git credential helper — implies a human-owned token, which doesn't fit unattended provisioning.
2. An SSH deploy key enrolled on blinkbitcoin/argit — implies repo-admin action per key.
3. GitHub Actions / OIDC short-lived tokens — works inside CI but not on agent VMs.

For consumers running argit on production hosts that don't share credentials with a developer, none of these are operationally viable at scale.

Concrete consumer scenario

Our bot-provisioning framework generates a per-instance ed25519 deploy key for each agent VM. That key is registered on the per-agent *-workspace GitHub repo (one workspace repo per agent). The same key is NOT — and operationally cannot be — enrolled on the upstream blinkbitcoin/argit repo, because:

• Enrolling N per-instance keys on blinkbitcoin/argit requires repo-admin action per VM. We provision hundreds of agent instances; admin-touch-per-provision is infeasible.
• Enrolling a single shared key would mean every VM holds the same private key, which defeats the per-instance isolation the framework's deploy-key model is built on.
• We can't grant our per-instance VMs an org-wide PAT with repo scope — that token would have read access to every blink-org repo, which exceeds the principle of least privilege.

Result: there is currently no install path from a fresh agent VM to a working argit binary that doesn't either (a) embed broad-scope credentials on the VM, (b) require per-VM repo-admin enrollment, or (c) ship the argit binary out-of-band.

Use cases blocked

• Any provisioning system installing argit on per-instance/per-tenant hosts.
• CI runners outside the blinkbitcoin GitHub org (e.g. operator's local dev machine running provisioning scripts).
• Fork / mirror deployments by other orgs.
• Reproducible builds that should not require live GitHub auth.
• Air-gapped or restricted-egress environments.

What we tried as a workaround

• Using the framework's per-VM workspace deploy key for argit install: returns Permission denied (publickey) because that key has no access to blinkbitcoin/argit.
• Pre-bundling the argit wheel into our framework's distribution: works but couples argit's release cadence to our framework's release cadence and bypasses argit's own version pinning model.
• Asking ops to enroll a single shared SSH key in blinkbitcoin/argit and distribute its private half to every VM via the provisioning secret store: works but is the "shared key" anti-pattern from above.

None are acceptable as a permanent solution.

Use cases blocked (broader)

This isn't only about our framework. Any consumer who wants to:

• Pip-install argit from a non-Blink machine
• Curl-install argit on a CI runner
• Run argit --version on a fresh container
• Pull argit's binary into a Docker image build

...is blocked unless they happen to be inside the Blink GitHub org with appropriate access.

What we'd like to see (problem space, not solution)

A supported install channel that does NOT require per-installer GitHub access to the private argit repo. There are well-trodden options:

• PyPI — publish to the public Python Package Index. pipx install argit / pip install argit / uv tool install argit would Just Work. Argit's tagline is "agent backup/restore via git" — the binary itself isn't secret; only the workspaces it backs up are.
• Public mirror repo — automatically mirror tagged releases to a public repo (e.g. blinkbitcoin/argit-public). Install URL becomes git+https://github.com/blinkbitcoin/argit-public@TAG.
• GitHub Releases as the artifact channel — even with the repo private, releases (with assets like argit-v1.8.0-py3-none-any.whl) can be downloaded with a public token under some org settings. Or sign the wheels and let consumers verify.
• Conda-forge / Homebrew / OS package managers — for users on those ecosystems.

We don't have a preference. We just need ONE supported, documented, auth-free install path.

Related: if argit is intentionally private because of bundled secrets/keys (the it-backup-pubkey.asc is a public key, so the bundled-keys reason wouldn't apply), the underlying issue is the bundle composition rather than the distribution channel — happy to discuss separately.

Discovered while integrating argit into bot-provisioning-poc (tech-spec-11 argit-integration); the T1 system_deps + T2 install steps cannot complete on agent VMs without solving this.