Peer dependency range accepts Pi versions that cannot load SoL-Pi #11

Summary

SoL-Pi declares all Pi packages as "*" peer dependencies, but the extension does not load with older versions that satisfy that range. In an isolated install with Pi 0.79.10, the compatibility check and package import fail because @earendil-works/pi-ai/compat was not exported yet.

The compatibility documentation identifies Pi 0.81.1 as the exercised baseline, so the peer range should communicate that minimum instead of allowing npm to accept incompatible installations.

Reproduction

Observed from main commit 22277b7e0c3c46ba1259a6687f31fe39ade421a5 with Node.js v22.22.2.

1. Copy the repository to an isolated directory.
2. Set these development packages to 0.79.10:

{
  "@earendil-works/pi-agent-core": "0.79.10",
  "@earendil-works/pi-ai": "0.79.10",
  "@earendil-works/pi-coding-agent": "0.79.10",
  "@earendil-works/pi-tui": "0.79.10"
}

3. Install and run:

npm install --ignore-scripts --legacy-peer-deps
node scripts/check-pi-compat.mjs

Actual result:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './compat' is not defined by "exports" in .../@earendil-works/pi-ai/package.json

Importing src/sol-pi/index.ts fails for the same reason because the top-level entry statically reaches the reducer provider module, even when Evidence-Preserving Reducer would be disabled by configuration. Pi 0.79.10 also predates public APIs used by Online Context Compact, including agent_settled and sessionEntryToContextMessages.

For comparison, the same isolated procedure with all four Pi packages at 0.81.1 passes:

node scripts/check-pi-compat.mjs  # exit 0
npm run typecheck                 # exit 0
import('./src/sol-pi/index.ts')    # load ok

Actual behavior

package.json declares:

"@earendil-works/pi-agent-core": "*",
"@earendil-works/pi-ai": "*",
"@earendil-works/pi-coding-agent": "*",
"@earendil-works/pi-tui": "*"

Package managers therefore consider Pi 0.79.10 compatible, although SoL-Pi cannot load with it.

Expected behavior

The peer dependency contract should express the tested minimum Pi version documented in docs/compatibility.md (currently 0.81.1), consistently across the Pi packages that must share a release line.

A focused regression could validate the lower-bound installation/import in CI or add a package-metadata assertion so the declared range cannot drift below the documented compatibility baseline.

I would be happy to prepare the package metadata and compatibility-check update if this minimum-version policy matches the project's intent.