feat: use pi-factory for pi launch wiring

[dutifulbob]

Opened on behalf of Onur Solmaz (osolmaz). This PR is ready for review.

Depends on dutifuldev/pi-factory#1.

Summary

localpi had its own Pi config generation and Pi process launch wiring.
This change moves that generic Pi-app work to Pi Factory and keeps localpi focused on local model/runtime discovery.
It removes duplicated config/spawn code while preserving localpi's behavior and tests.

What Changed

localpi now builds a Pi Factory app definition after it resolves the local runtime and selected model.
Pi Factory writes the Pi runtime config and creates/executes the launch plan.

• Added a small src/pi/app.ts adapter from localpi runtime state to a Pi Factory app definition.
• Replaced localpi's duplicated models.json / settings.json writer with writePiRuntimeConfig.
• Replaced localpi's duplicated Pi spawn/argument construction with createPiLaunchPlan and execPiLaunchPlan.
• Kept localpi-owned runtime behavior in localpi: provider discovery, model selection, managed llama-server, demo mode, thinking settings, and extensions.

Testing

I tested this without loading any new model into memory and without starting a real model-backed Pi session.
The existing tests use fake local runtimes and fake commands.

• npm run format
• npm run lint
• npm run typecheck
• npm test
• npm run build
• npm run check

Risks

The main risk is dependency ordering.
localpi depends on the Pi Factory branch from PR #1 until Pi Factory is merged and released.

• Runtime behavior should be low risk because the existing localpi tests still pass.
• Real model-backed interactive smoke was intentionally not run because a training job is active on this machine and we should not load new models or risk OOM.

[dutifulbob]

Autoimplementation update:

• localpi now uses pi-factory for Pi app definition, runtime config generation, and launch-plan construction.
• Preserved localpi --pi-command shell semantics for existing users.
• Refreshed the pi-factory dependency to the latest PR branch commit.
• Verified locally with npm run check.
• CI is green, including coverage, DRY, mutation, and Slophammer.

[dutifulbob]

Final report for the latest implementation pass:

• Refactored localpi to build a single Pi app definition and use it for runtime config and launch planning.
• Removed localpi's duplicate launch executor and centralized execution in pi-factory.
• Moved localpi version metadata behind a single package metadata helper inside the src/pi boundary.
• Split generated Pi extension source builders into focused modules and added a transpilation regression test for all generated extension sources.
• Preserved shell-style --pi-command / LOCALPI_PI_CMD behavior through a pi-factory fix and added a localpi regression test for env-assignment shell commands.

Validation run locally:

• npm run check in localpi: passed, 147 tests.
• npm run slophammer in localpi: passed.
• npm run check in pi-factory: passed, including coverage, DRY, boundaries, and Slophammer.

CI:

• localpi PR CI is green on 49b0744, including check, coverage, DRY, mutation, and Slophammer.

Note:

• @dutifuldev/pi-factory@0.1.1 is pushed on pi-factory main and passed CI checks, but npm publish is blocked by npm registry permissions for the CI token: npm returned 404 PUT @dutifuldev/pi-factory. Until that token/scope permission is fixed, this PR pins the exact fixed pi-factory GitHub commit.