docs(specs): add Pi native extension spec (lane 2, #123)

[L2ncE]

Summary

Spec-only PR for lane 2 of #72's suggested split, opened per @phodal's guidance: a fresh design spec before implementation, linked to #123.

docs/specs/2026-08-28-123-pi-native-extension.md covers the native Pi /better-harness extension scope:

• single-command takeover from the prompt template (removes prompts/better-harness.md from Pi discovery),
• isolation, privacy, cancellation, and failure boundaries (isolation flag set verified against pi 0.84.3; LF-only JSONL framing, readline prohibited per the RPC doc),
• focused extension and package/discovery test evidence,
• a real interactive report-loop smoke receipt as the implementation PR's completion gate (run on this repository itself; I'll also run it on a private project as additional evidence).

Open decision for spec review

The #72 extension imported the shared host-runtime contract introduced by that same PR, which is not on main. The spec presents both paths phodal outlined and recommends Option B: Pi-private orchestration inside extensions/pi/ calling existing main contracts, with no shared contract introduced and no lane-1 scope duplicated. Marked [NEEDS CLARIFICATION] for maintainer confirmation.

Scope check

No WorkBuddy, no generalized provider/reporting changes, no release metadata, no unrelated host-runtime work. Docs-only diff: one new spec file. doc-link-graph suite passes (8/8).

Spec stage only; implementation PR to follow after spec review. Tracking issue: #123 (do not auto-close).

[L2ncE]

cc @phodal — spec is up for review per your guidance in #123. The main open question is the lane-1 dependency (Option A vs B, detailed in the spec's "Open Decision" section). @NickyLam please flag if you're already preparing this lane.

[phodal]

The overall direction looks reasonable, and I confirm Option B—there’s no need to wait for the shared host runtime. Please keep the Pi extension limited to RPC orchestration and lifecycle management, while reusing the canonical evidence, lane semantics, schema, and rendering contracts.

[L2ncE]

@phodal thanks for confirming Option B. I've updated the spec accordingly (38f2c9c): the open decision is now a recorded decision with your confirmation link and your scope constraint quoted verbatim ("RPC orchestration and lifecycle management only, reusing the canonical evidence, lane semantics, schema, and rendering contracts"), and the status moved from Draft to Accepted.

If the spec looks good to merge as-is, I'll start the implementation branch next (focused on the extension, tests, and the interactive report-loop smoke receipt).

[phodal]

Option B is confirmed, but my comment only confirmed the architectural direction, not the full spec as Accepted. Please keep it as Draft until the lifecycle, canonical lane binding, and packaging acceptance criteria are clarified.

[phodal]

You can proceed with the implementation while keeping the spec in Draft. Please use implementation and test findings to refine the lifecycle, lane-binding, and packaging contracts before merging.