Bundle pi CLI in daemon release tarball (size + version-pinning consideration)

[glittercowboy]

Context

After #46 lands, the install flow is:

1. `curl ... | sh` downloads daemon + pi-extension source
2. Installer runs `npm ci` to fetch SDK native binaries on user machine
3. User must separately have pi installed: `npm install -g @mariozechner/pi-coding-agent`

Step 3 is a manual prerequisite. Users hit confusing failures if pi isn't installed (pi spawn fails at first chat message, daemon error message is opaque). `gsd-cloud doctor` (also #46) will diagnose this, but it's still a manual remediation step.

Question

Should we bundle pi into the daemon release tarball so the install is truly one-step?

Pros:

• Zero-prereq install (just need npm + claude)
• Version pin: daemon and pi versions stay locked together (eliminates a debug variable)
• Eliminates "is the user's globally-installed pi the right version" support burden

Cons:

• pi + its node_modules is ~228MB on disk (needs verification of tarball size after npm prune)
• Adds another vendored dep to keep current with Anthropic SDK + GSD compatibility
• pi is MIT-licensed, so legally fine to redistribute

Recommended approach

If we do this:

1. Vendor pi as `pi-cli/` next to `pi-extension/` in the release tarball
2. Daemon's `GSD_PI_BINARY` defaults to the vendored copy if no env override
3. Release workflow installs pi via `npm install --no-save` + `npm prune --omit=dev` to minimize size
4. Doctor command checks the vendored copy first, falls back to PATH

Out of scope for this issue

• Bundling Claude Code itself (proprietary, not redistributable — see install message)
• Per-platform tarballs (current single tarball + npm-on-install handles platform diffs cleanly)

Decision needed

@lexchristopherson — worth doing now, or wait until enough users hit the missing-pi issue?