`--checkpoint-remote` supports only the `github` provider — no self-hosted/generic git remote option

Title: --checkpoint-remote supports only the github provider — no self-hosted/generic git remote option

Problem

entire configure --checkpoint-remote only accepts github:owner/repo. Any other provider is rejected:

$ entire configure --checkpoint-remote https://vc.hub.msg.team/org/checkpoints-repo.git
invalid --checkpoint-remote: unsupported provider "https" (supported: github)

There's no way to point checkpoint storage at a self-hosted git server (Gitea, GitLab CE/EE, or a plain bare git repo over HTTPS/SSH). Confirmed this isn't a stale-CLI issue — the restriction is identical in the latest nightly (v0.10.1-nightly.202608180612):

• parseCheckpointRemoteFlag (cmd/entire/cli/setup.go) hardcodes checkpointProviderGitHub = "github" as the only accepted value.
• settings.CheckpointRemoteConfig stores just {Provider, Repo} — two strings, no host/URL field.
• The strategy layer (cmd/entire/cli/strategy/checkpoint_remote.go) derives the push URL by taking the origin remote's protocol (SSH vs HTTPS) and substituting github.com/<repo> directly — there's no override point, even by hand-editing .entire/settings.json.

So this isn't a validation-only restriction that a raw JSON edit can route around; github.com is baked into the URL construction.

Why this matters

Not every team hosts on github.com. Internal/on-prem git servers (Gitea, GitLab self-managed, plain bare repos) are common in enterprise setups, and checkpoint storage is exactly the kind of data (AI session transcripts) teams want to keep on infrastructure they control rather than route through GitHub.

Related issues

• #377 ("Plans for GitLab integration") — closed as no-current-plans; a commenter pointed at a third-party bridge (sunmh207/entire-dashboard) as a workaround for GitLab specifically. Doesn't cover generic/self-hosted git remotes.
• #1433 ("Pluggable checkpoint stores: abstraction refactor") — the internal refactor toward a pluggable GitStore/DualGitStore abstraction. This looks like the right foundation for a generic-remote provider, but the issue itself doesn't request one.
• #340 ("Storing AI transcripts on a git branch is architecturally problematic for privacy") — adjacent motivation (keep transcripts off the main repo's access model), different angle from "let me choose where the git remote is hosted."

Request

Add a provider (or a generic git:<url> form) that lets --checkpoint-remote target an arbitrary git remote — self-hosted Gitea/GitLab, or a plain bare repo over HTTPS/SSH — instead of hardcoding github.com. Given #1433's pluggable-store work is in progress, this may be a natural addition once that lands; flagging now so it's tracked as a concrete use case.

Environment

• entire CLI 0.9.0 (darwin/arm64), reproduced against latest nightly source (v0.10.1-nightly.202608180612.e2de3d346)

Start with parseCheckpointRemoteFlag in cmd/entire/cli/setup.go, settings.CheckpointRemoteConfig, and cmd/entire/cli/strategy/checkpoint_remote.go; compare their assumptions with the pluggable GitStore/DualGitStore work in issue #1433. Done means a supported generic or self-hosted remote can be configured and checkpoint pushes use that remote rather than a hardcoded github.com URL.