fix: bootstrap engine binary on first run via committed wrapper

[5uck1ess]

Problem

v2.1.0/v2.1.1 shipped a critical silent failure. plugin.json pointed the MCP server at \${CLAUDE_PLUGIN_ROOT}/bin/devkit, but bin/ was in .gitignore, so the marketplace-installed plugin contained no binary. The MCP server silently failed to start. Hooks loaded but had no session state to read. Enforcement silently did nothing. Every user who installed 2.1.0 got a broken engine, and workflows fell back to direct agent dispatch without anyone noticing.

The real cause wasn't just a missing file — it was the absence of a CI check that would have caught the shipping tree not matching runtime expectations.

Fix

1. bin/devkit wrapper (committed POSIX sh)

• If bin/devkit-engine exists (dev build from make install-plugin), exec it directly — fast path, no network.
• Otherwise: read version from plugin.json, detect OS/arch, download the matching devkit-<os>-<arch> asset from the GitHub release for that version, verify its SHA256 against the release's checksums.txt, cache the binary alongside the wrapper as devkit-engine-v<ver>-<os>-<arch>, then exec it.
• All log output goes to stderr — stdout stays clean for the MCP stdio protocol.
• Failure paths are loud: missing curl/sha256sum, bad checksum, 404, unsupported platform all produce clear messages and exit 1. No silent degradation.

2. .gitignore — commit the wrapper, ignore the binaries

```
bin/devkit-engine
bin/devkit-engine-*
bin/.checksums.*
src/bin/
```

3. Makefile — split dev build from release cross-compile

• `BINARY := devkit-engine` — local build output (what the wrapper's fast path looks for)
• `RELEASE_BINARY := devkit` — cross-compile output (`bin/devkit-linux-amd64` etc.), preserves release asset naming that the wrapper downloads
• `sync-version` no longer downgrades `plugin.json` — only writes when the git tag is strictly higher than the current version. This prevents `make build` on a feature branch from clobbering manual version bumps.

4. CI `fresh-install-smoke` job — the class-of-bug guard

This is the thing that would have caught the v2.1.0 bug before merge. On every PR, in a clean checkout:

• Asserts `bin/devkit` exists and is executable
• Asserts `bin/devkit-engine` is not committed (it's a cache, should never be tracked)
• Asserts `plugin.json`'s MCP command matches the committed wrapper path exactly
• Runs `shellcheck` on the wrapper
• Runs `./bin/devkit --version` from the clean checkout and confirms it either succeeds or fails loudly — never exit 0 with empty output (the silent-failure pattern)

5. Removed `presets/` — empty v1 directory with only `.gitkeep`, zero references.

Tested locally

Scenario	Result
`shellcheck bin/devkit`	clean
`./bin/devkit --version` with local engine	fast path, exit 0
`./bin/devkit --version` with no local engine, valid version	downloads, verifies, installs, execs, exit 0
Second run (cache hit)	instant exec, no network
Invalid version (99.99.99)	404, loud stderr error, exit 1
`go build ./... && go test ./... -race`	all pass

Why this is the right shape

The wrapper pattern is how npm, rustup, and homebrew handle platform-specific binaries. Shipping all 6 platforms in git would be ~60MB; committing a shell script that downloads the right one on first run is ~30 lines and auto-heals on version bumps.

More importantly: the CI smoke test is the real prevention. A future change could reintroduce the same class of bug (wrong path, missing file, broken plugin.json), and the smoke test catches it the same way every time.

Test plan

• CI passes including the new `fresh-install-smoke` job
• After merge + release, verify plugin auto-updates to 2.1.2
• Restart Claude Code in a session that had 2.1.1 installed, confirm wrapper downloads 2.1.2 engine on first MCP tool call
• Confirm `devkit:tri-review` workflow dispatches via the engine (it couldn't on 2.1.0/2.1.1 because the binary was missing)