Docker image GitHub release fallback

[thunderock]

Description

Describe what this change achieves

Issues Resolved

List any existing issues this PR resolves

Check List

• New functionality includes testing.
• New functionality has been documented in the README if applicable.

[johannesjo]

Thanks for this @thunderock — there's genuinely nice engineering in here, but as it stands I can't merge it. Let me explain clearly so we can salvage the good part.

The blocker: this PR is a rebranded fork, not a feature

The branch carries a wholesale rename of the project from Parallel Code → Forge and reassigns its identity. Across the ~80 files, these stand out:

• .github/FUNDING.yml — sponsorship redirected johannesjo → thunderock
• package.json — author, productName (Forge), appId (com.forge.app), and the GitHub publish target all changed to thunderock/forge
• .github/workflows/release.yml — removes macOS code signing + notarization (cert import, notarization API key, and cleanup steps deleted; switches to CSC_IDENTITY_AUTO_DISCOVERY=false + -c.mac.notarize=false). Official releases would become unsigned and get blocked by Gatekeeper.
• electron/ipc/updater.ts — disables the post-launch auto-update check
• .github/workflows/docker-image.yml — pushes to docker.io/thunderockforge/forge-agent using DOCKERHUB_* secrets this repo doesn't have

There's also a silent breaking change for existing users: renaming productName/appId moves the Electron userData directory (~/.config/Parallel Code → ~/.config/Forge, and the macOS equivalent), so everyone's tasks, settings, themes, and keybindings would disappear with no migration. Same for the on-disk .parallel-code/ → .forge/, the MCP server key parallel-code → forge, and PARALLEL_CODE_MCP_TOKEN → FORGE_MCP_TOKEN.

I'm assuming the branch was opened by mistake — it looks like your fork's main rather than an isolated feature branch.

The good part I'd love to keep

The Docker image-acquisition fallback in electron/ipc/docker-pull.ts is well done — dependency-injected, fully abortable (renderer reload / kill / kill-all all cancel in-flight pulls cleanly), retry + backoff, SHA-256 verified, with a solid ~300-line test suite. The layered chain (cached → docker pull → GitHub-release tarball + docker load → local build) genuinely solves the egress-less-VM problem (Colima/Lima under a VPN, where the daemon can't reach a registry but the host can). The pty.ts refactor that wraps the spawn body in a launch() closure so acquisition can run first is clean too.

What I'd ask

Could you close this and open a branch cut fresh from main containing only the Docker feature:

• electron/ipc/docker-pull.ts + its test
• the pty.ts image-acquisition wiring
• the release.yml agent-image tarball-upload job — without the signing/notarization removal
• image name, owner/repo, and any registry namespace pointing back at parallel-code / johannesjo

…and drop every Parallel Code → Forge / thunderock identity change (FUNDING, package.json, updater, rename churn, icons/SVGs, test fixtures).

Two smaller notes for that version:

• docker-pull.ts — the checksum is only enforced when the .sha256 asset is present; a missing/404 checksum loads the tarball unverified. Fine as a deliberate degrade, but worth a comment (or fail-closed for the default image).
• dockerImagePresentSync — runs execFileSync with a 4s timeout on the synchronous spawn fast-path, i.e. on the Electron main thread; a hung Docker daemon would freeze the UI for up to 4s at launch. Consider keeping that path async.

Happy to review the moment it's a clean feature-only diff. Thanks again — the fallback design itself is exactly the kind of resilience I want.