[Feature]: Native Pi extension — pick up lane 2 from #72's suggested split

[L2ncE]

What problem are you trying to solve?

PR #72 was asked (see @phodal's review on Aug 24) to be closed or superseded and split into three focused PRs:

1. Shared host-runtime and provider-coverage contract, with focused tests.
2. Native Pi extension and its verified compatibility boundary.
3. WorkBuddy Team plugin, packaging, and host-specific documentation.

Since then, none of the three split PRs have appeared and #72 has diverged from main. The native Pi extension piece is currently in limbo: Pi users have adapter-level support from #25 (skill + prompt template, session evidence, portable HTML), but no host-native extension runtime, and plugin plan/apply lifecycle operations remain unavailable for Pi ("persistent Pi operations without native evidence stay unavailable" per the adapter matrix).

What would success look like?

A fresh, focused PR from latest main delivering only lane 2: the native Pi /better-harness extension with its verified compatibility boundary, focused tests, and the minimum docs required by that scope — none of the shared host-runtime contract or WorkBuddy changes.

Ideally it would also come with evidence from a real interactive Pi report-loop smoke. That is exactly the missing observation for Pi's current "Adapter support" status: "Pi remains outside the verified Quickstart set until a complete interactive report-loop smoke is observed." As a daily Pi user (running it as my primary coding agent), I can run that smoke on real sessions and contribute the evidence.

Where would this be used?

Pi host: pi install / pi -e discovery, the extension runtime (extensions/pi/ direction from #72), plugin lifecycle status for Pi, and the adapter matrix Pi row.

Examples or evidence

• feat(hosts): add native Pi and WorkBuddy plugin runtimes #72 — the original combined PR with the full extensions/pi/better-harness.ts implementation that can serve as a reference for the split.
• feat(hosts): add Pi coding agent host adapter #25 — the merged Pi host adapter that this builds on.
• Adapter matrix — current Pi boundary and the Quickstart gap.

Anything else?

• Coordination question for @NickyLam: if you're already preparing the split PRs, I'm happy to step aside or take a different lane instead — just let us know.
• Question for maintainers: would an external contributor picking up lane 2 be welcome, and would you want a fresh spec doc (e.g. docs/specs/2026-09-xx-pi-native-extension.md) before implementation, following the pattern in feat(hosts): add native Pi and WorkBuddy plugin runtimes #72?
• I'm willing to contribute the implementation and the interactive smoke evidence.

[phodal]

Thanks for opening this as a focused follow-up, and especially for offering to provide a real interactive Pi smoke. An external contribution for lane 2 is welcome.

Please start from the latest main and treat #72 as design/reference material rather than continuing or cherry-picking the old branch wholesale.

Before implementation, please open a fresh spec linked to #123, for example:

docs/specs/2026-08-28-pi-native-extension.md

The intended scope is:

• the native Pi /better-harness extension and collision-free discovery;
• its isolation, privacy, cancellation, and failure boundaries;
• focused extension and package/discovery tests;
• only the Pi-specific installation and adapter documentation required by this change;
• a real interactive report-loop smoke receipt, if available.

Please keep WorkBuddy, generalized provider/reporting changes, release metadata, and unrelated host-runtime work out of this PR.

One dependency needs to be resolved in the spec first: the extension implementation in #72 imports the shared host-runtime contract introduced by the same PR, and that contract is not currently on main. The focused lane-2 PR should therefore either:

1. build on lane 1 after that contract lands separately; or
2. demonstrate a Pi-only implementation against existing main contracts without duplicating or reintroducing lane 1.

We can decide between those during spec review.

Also, the interactive Pi smoke may close the current report-loop evidence gap and support reconsidering Pi’s Quickstart status. It would not by itself make persistent plugin plan/apply lifecycle operations verified; those require separate native install/update/remove evidence.

@NickyLam, please let us know if you are already preparing this lane so the work can be coordinated.