chore: rename external-tools.json to bundle-tools.json

[John-David Dalton (jdalton)]

Summary

• Rename external-tools.json → bundle-tools.json to clarify its purpose as a VFS bundling manifest (npm packages, GitHub releases, PyPI packages with checksums)
• Avoids confusion with the external-tools.json used by build-infra in sibling repos (socket-btm, ultrathink) which is a build tool config
• All source references updated (scripts, src, test setup)

Test plan

• Unit tests pass (pre-commit hook verified)
• Build scripts resolve bundle-tools.json correctly

---

Note

Low Risk
Low risk rename-only change, but any missed reference to external-tools.json will break SEA build/test setup by failing to load tool versions/checksums (e.g., .env.test comments still mention the old name).

Overview
Renames the CLI bundling manifest to bundle-tools.json and updates SEA download/bundling scripts, checksum sync tooling, test setup, and env/version/checksum error messaging to read from the new filename.

This is primarily a wiring/docs update: all places that load tool versions/checksums for inlining and integrity verification now point at bundle-tools.json instead of external-tools.json.

^{Reviewed by Cursor Bugbot for commit ee16d6d. Configure here.}

[John-David Dalton (jdalton)]

Revised schema proposal (addressing review feedback)

The initial proposal had 3 blocking issues. Here's the updated design:

Problem 1: sfw is dual-source (GitHub binary in SEA, npm package in CLI dlx)

Fix: Allow both repository and packageManager with separate versions:

"sfw": {
  "description": "Socket Firewall",
  "repository": "SocketDev/sfw-free",
  "release": "asset",
  "version": "v1.6.1",
  "checksums": { ... },
  "npm": {
    "package": "sfw",
    "version": "2.0.4"
  }
}

The npm object is the secondary source. Primary source is the GitHub release asset.

Problem 2: buildTag is needed for Python URL construction

Fix: Keep buildTag — it's part of the asset URL pattern, not redundant:

"python": {
  "description": "Python runtime",
  "repository": "astral-sh/python-build-standalone",
  "release": "asset",
  "version": "3.11.14",
  "buildTag": "20260203",
  "checksums": { ... }
}

Problem 3: PyPI vs GitHub-source — both use pip but download differently

Fix: release: "archive" + repository distinguishes GitHub-source from PyPI. No repository = PyPI:

// PyPI package (no repository)
"socketsecurity": {
  "description": "Socket Python CLI",
  "version": "2.2.70",
  "packageManager": "pip",
  "checksums": { ... }
}

// GitHub source installed via pip (has repository + release: "archive")
"socket-basics": {
  "description": "Socket Basics",
  "repository": "SocketDev/socket-basics",
  "release": "archive",
  "version": "v2.0.2",
  "packageManager": "pip",
  "checksums": { ... }
}

The presence of repository + release: "archive" tells the downloader to use /archive/refs/tags/ URL. Absence of repository with packageManager: "pip" means PyPI.

Problem 4: Rename docs/external-tools.md too

docs/external-tools.md → docs/bundle-tools.md

Final property table

Property	Purpose	When used
description	What it is	Always
version	Version string	Always
repository	owner/repo (GitHub default) or host:owner/repo	GitHub sources
release	"asset" or "archive"	With repository
buildTag	Extra tag for URL construction	When release URL needs it (python)
packageManager	"npm", "pip", "pnpm"	Registry installs
checksums	SHA-256 per artifact	All downloads
integrity	SRI hash	npm packages
npm	Secondary npm source {package, version}	Dual-source tools (sfw)
notes	Human notes	Optional