Oh My Pi kept the unresolved $COMMAND_CODE_API_KEY placeholder as a literal config API key that shadowed its /login credential store and was sent as the Bearer token (401). The placeholder is now registered only on pi, where it keeps the API-key auth method and --api-key working next to OAuth; on OMP the provider omits apiKey unless a real key is configured. Host-supplied placeholders are resolved or stripped on every stream path, and the legacy generate transport uses the same rule.
Stored /login OAuth and API-key credentials, --api-key, and env keys are now covered end to end on both pi and Oh My Pi, and CI runs the pi suite against a real binary.
Co-authored-by: ebreen <ebreen@users.noreply.github.com>
Bump the memory benchmark runtime pins to the current stable releases:
Bun 1.3.11 -> 1.4.0, Node 22.19.0 -> 22.23.2, pi host 0.82.1 -> 0.84.4.
Pin the Oh My Pi compatibility job to the same Bun release instead of
'latest' so a required check does not drift on its own.
tests/test-omp-compat.mjs skipped whenever omp was not on PATH, which
was always the case in CI, so 0.6.1 shipped an import that pi's compat
entrypoint provides but OMP's bundled pi-ai does not (#74).
Add an omp-compat job that installs @oh-my-pi/pi-coding-agent with Bun
and runs the suite with OMP_COMPAT_REQUIRED=1, which turns the skip into
a failure. Add a first phase that loads the extension through
`omp models -e`, the same loader `omp plugin install` validates with;
it fails on the 0.6.1 index.ts and passes with the runtime resolution.
execFile cannot spawn npm's .cmd shim directly on Windows, so the catalog
sync and drift check failed with spawn npm ENOENT. Route npm invocations
through the shell with argument quoting on Windows and keep direct
execFile calls elsewhere.
