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.
