feat: add pi package publishing to release workflow

[dbmrq]

Summary

Adds automatic publishing of a pi package (`little-coder-pi`) alongside the main `little-coder` npm package on tagged releases.

Changes

• scripts/build-pi-package.mjs: New script that builds a pi-compatible package from the little-coder source tree
• package.json: Added `build:pi-package` npm script
• .github/workflows/publish.yml: Added `publish-pi-package` job that runs after the main publish job
• .gitignore: Added `dist/` to ignore build artifacts

What the pi package includes

• 23 extensions (all current little-coder extensions)
• 3 skill categories (tools, knowledge, protocols)

How it works

When a version tag is pushed (e.g., `v1.9.12`):

1. Main `publish` job publishes `little-coder` to npm
2. New `publish-pi-package` job builds the pi package from source
3. Publishes `little-coder-pi@1.9.12` to npm with provenance

For users

Vanilla pi users can now do:
```bash
npm install little-coder-pi
```
And get all little-coder extensions/skills auto-loaded via pi's package system.

Testing locally

```bash
npm run build:pi-package

Output in ./dist/pi-package

```

[dbmrq]

This PR clearly wasn't ready to be published yet, but little-coder did it by itself. 😂

I marked it as a draft, but the idea would be to also publish the little-coder extensions and skill system (minus benchmarking stuff) as a regular pi package. I know little-coder goes beyond this, but I still think many of the additional extensions would be valuable for pi independently, and it would be convenient to be able to install them with something pi install little-coder. What do you think of this idea, @itayinbarr ?

[itayinbarr]

Ha — I love that little-coder shipped its own PR by itself 😄.

And I like the idea a lot. A good chunk of these extensions — read-guard, evidence, thinking-budget, tool-gating, plan-mode, the skill-inject/knowledge-inject system — are genuinely useful to vanilla pi users independent of the small-local-model angle, and pi install <something> would be a clean way to get them. Happy to see this move forward.

If you want to take it further, here's what I'd want before merging:

• Naming + scope. A distinct package name (e.g. pi-little-coder), and an explicit, documented allowlist of what ships. Your PI_PACKAGE_EXTENSIONS list is a good start — but some clearly don't belong (branding, llama-cpp-provider, and anything benchmark-related are little-coder-runtime-specific, not general pi value).
• Sync strategy. The build copies from .pi/extensions/ at publish time, so the pi-package needs to track the main version and there should be a note in the release flow so it doesn't silently drift. A small test that the build produces a loadable package would go a long way.

One important caveat to set expectations, and it's the crux: not everything little-coder does is "just an extension." Several load-bearing behaviors are applied by adapting pi itself, not by adding extensions on top:

• scripts/patch-pi.mjs re-applies source edits to the installed pi on every launch (e.g. suppressing pi's bare "Operation aborted" marker). That's patching pi, not extending it.
• Launcher-level wiring — --no-extensions plus an explicit load order, the global-settings merge (quietStartup, pinning lastChangelogVersion), the update flow, the llama.cpp context re-probe — lives in bin/, not in any extension.

None of that comes along in a pi install package. So what you'd be shipping is a curated subset of the extension layer, not little-coder-in-a-box — and the two will behave differently in places precisely because the wrapper/patch layer isn't there. Worth calling that out plainly in the package README so users aren't surprised when, say, an aborted-run marker shows up or startup is chattier than it is under little-coder.

If you're up for it, finish it along those lines and un-draft when it's ready — I'll review properly. Thanks for pushing on this one.