v0.9.4

Every install channel now ships from a tagged release instead of main.

Until now both the manual curl and /claude-pace:setup fetched raw.githubusercontent.com/.../main/claude-pace.sh, so what you installed was whatever main happened to be at that second — not a version anyone could name, reproduce, or roll back to. Releases, tags and the npm package recorded versions but were never what actually shipped.

The issue was reported against the manual curl only, but setup.md ran the same command, so the "recommended" plugin path was installing main too.

• /claude-pace:setup makes no network calls. It copies ${CLAUDE_PLUGIN_ROOT}/claude-pace.sh, the script the plugin already bundles. The plugin was downloading a second copy of a file it was carrying — a package manager ignoring its own package. There is deliberately no curl fallback: a missing bundled script means a broken plugin install, and the command stops and says so.
• Marketplace entry pins to the release tag. The previous "source": "./" served the default branch, so pinning setup.md alone would still have handed new installs the contents of main.
• Manual install pulls releases/latest/download/claude-pace.sh, with releases/download/vX.Y.Z/claude-pace.sh documented for pinning an exact version.
• The manual curl gained the -f it was missing. Without it a 404 exits 0 and writes the literal text Not Found into ~/.claude/statusline.sh, which the next line then chmod +x. This was a live defect independent of the version-pinning issue.

What this does and does not buy: bad code now has to pass through an explicit release action to reach users, which blocks accidental merges, unreviewed pushes, and force-pushes to main from shipping directly. It does not defend against anyone who can publish releases or a compromised maintainer account, and a lightweight tag remains a movable ref.

Upgrading an existing plugin install:

/plugin marketplace update claude-pace-marketplace
/plugin update claude-pace
/reload-plugins
/claude-pace:setup

Reported in #16.