fix(security): replace curl-pipe-bash installers, harden SSH host checking, document Docker socket risk

[polerix]

Summary

This PR addresses four security improvements I noticed while setting up Phantom on a Mac Mini M4. All changes are backwards-compatible and the install behaviour is preserved — this is purely about replacing patterns that carry unnecessary risk.

---

1. Replace curl | bash Docker install with a verified package install

Before (scripts/install.sh):

curl -fsSL https://get.docker.com | bash

After:

• macOS: brew install --cask docker — installs Docker Desktop via a signed Homebrew cask, no arbitrary code execution
• Linux: Uses the official Docker apt repository with GPG key verification, following the documented procedure at https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

The curl | bash pattern executes whatever the remote server returns without any integrity check. Both replacements use cryptographically verified packages.

---

2. Replace curl | bash Bun install with a verified package install

Before (scripts/install.sh):

curl -fsSL https://bun.sh/install | bash

After:

• macOS: brew install oven-sh/bun/bun — installs from the official oven-sh Homebrew tap
• Linux: npm install -g bun — avoids the curl-pipe-bash pattern while staying within the npm trust model

Same rationale as above: eliminates arbitrary remote code execution during installation.

---

3. Fix StrictHostKeyChecking=no in deploy script

Before (scripts/deploy-to-specter-vm.sh):

SSH_OPTS="-o StrictHostKeyChecking=no -o ConnectTimeout=10"

After:

SSH_OPTS="-o StrictHostKeyChecking=accept-new -o ConnectTimeout=10"

StrictHostKeyChecking=no silently accepts any host key — including a forged one from a machine-in-the-middle attacker. accept-new trusts a host on first connect (same convenience for new VMs) but rejects changed keys on subsequent connections, which is the actual threat StrictHostKeyChecking is designed to catch.

---

4. Document the Docker socket mount trade-off in README

docker-compose.yaml mounts /var/run/docker.sock into the Phantom container. This is intentional and I've kept it as-is — it's needed for sibling container creation. However it carries a meaningful privilege: a compromised Phantom process could control the host's Docker daemon.

Added a callout block in the README Quick Start section noting the trade-off and recommending users run Phantom on a dedicated machine rather than a personal workstation.

---

Testing

Tested end-to-end on a Mac Mini M4 (Apple Silicon, macOS):

• brew install --cask docker → Docker Desktop 4.67.0 installed cleanly
• brew install oven-sh/bun/bun → Bun 1.3.11 installed cleanly
• bun install in repo root → 208 packages in 1.83s
• docker compose up -d → all three containers (phantom, qdrant, ollama) started and healthy
• curl localhost:3100/health → {"status":"ok","version":"0.17.0","memory":{"qdrant":true,"ollama":true}}

The SSH change is logic-only and wasn't tested against a live Specter VM, but accept-new is a well-documented drop-in replacement for no in this context.

[mcheemaa]

Verified E2E on a fresh https://github.com/ghostwright/specter VM (cx53, Ubuntu 24.04). Deploy script with accept-new connected cleanly, specter-agent removal worked, all three containers came up, health check passed, Slack connected, and the intro DM was delivered. Nice security work - the curl-pipe-bash replacement and SSH hardening are the right calls. One minor thing: the deploy script lost its executable permission in the diff (755 to 644). I'll fix that in a follow-up. Thank you for the contribution!