Add engine binary distribution — cross-compile, release, auto-bootstrap

[5uck1ess]

Summary

The Go engine was never distributed with the plugin. Every YAML workflow invocation fell through to markdown fallback instructions — Claude ran without any deterministic enforcement. This PR fixes that.

• Makefile: build-for (cross-compile for any GOOS/GOARCH) and build-all (6 targets: linux, darwin, windows x amd64, arm64)
• Release workflow: Rewritten to 4-stage pipeline — version bump → draft release → parallel binary matrix build → upload assets → publish. Cleanup job deletes draft on failure.
• Bootstrap script (scripts/install-engine.sh): Auto-detects platform, downloads the correct binary from GitHub releases, installs to /usr/local/bin, ~/.local/bin, or %LOCALAPPDATA%/devkit (Windows)
• Commands (tri-review, tri-debug, tri-security, pr-ready): Bootstrap check before devkit workflow run. Hard stop if engine unavailable — no fallback.
• Skills (research, deep-research, autoloop): Fallback markdown sections removed. Engine is required for determinism.
• Status command: Now reports engine installation health.

Why this matters

Without this, the entire deterministic workflow conversion (PRs #38-#44, ~3,600 lines of work) was theater. YAML workflows existed but the engine never ran them. Claude just read the fallback docs and did whatever it wanted.

Test plan

• cd src && make build-for GOOS=darwin GOARCH=arm64 produces bin/devkit-darwin-arm64
• cd src && make build-for GOOS=windows GOARCH=amd64 produces bin/devkit-windows-amd64.exe
• bash scripts/install-engine.sh --check exits 1 (binary not on PATH) or 0 (installed)
• Release workflow YAML is valid (check Actions tab after push)
• Commands no longer contain fallback markdown steps
• /devkit:status shows engine health section

[5uck1ess]

Windows PATH issue with %LOCALAPPDATA%/devkit

That directory isn't on PATH by default, so after install the binary won't be found by ensure-engine.sh or any shell invocation.

The Linux ~/.local/bin fallback already handles this with export PATH, but that only helps the current shell session. Windows has the same problem but worse — no export equivalent in bash-on-Windows that persists.

Recommendation: After installing to %LOCALAPPDATA%/devkit on Windows, add a setx call to persist it to the user's PATH:

if [[ "$OS" == "windows" ]]; then
    install_dir="$LOCALAPPDATA/devkit"
    mkdir -p "$install_dir"
    mv "$tmp/devkit.exe" "$install_dir/devkit.exe"
    export PATH="$install_dir:$PATH"  # current session
    # Persist to user PATH for future sessions
    powershell.exe -Command "[Environment]::SetEnvironmentVariable('Path', [Environment]::GetEnvironmentVariable('Path', 'User') + ';$install_dir', 'User')"
fi

Using [Environment]::SetEnvironmentVariable via PowerShell is safer than setx because setx silently truncates PATH if it exceeds 1024 characters. The PowerShell method has no such limit.

Alternatively, could install to %USERPROFILE%\go\bin if Go is present (already on PATH), but that couples devkit to a Go installation which not all users will have.