feat: read the API key from pi's auth.json + fallback to env var

[handrus]

Summary

Solves issue #1
Adds the explabs entry in pi's credential store (~/.pi/agent/auth.json) as an API key source, with EXPLABS_API_KEY as the fallback.

Credential values support the same syntax as models.json / /login values: a literal key, a $ENV_VAR / ${ENV_VAR} reference, or a leading !command for secret managers (e.g. "key": "!secret-tool lookup service explabs"). A !command is handed to pi unresolved, so pi expands it per request and caches the result; the extension resolves it itself only for its own /models fetch.

Resolution order: explicit extension config apiKey → auth.json → environment variable, so auth.json wins when both are set (matching pi's documented "auth file credentials take priority over environment variables").

Why

auth.json was being ignored: the extension always passes its own default apiKeyEnv, and resolveApiKey() treated any explicit apiKeyEnv as an opt-out of the credential store, making the auth.json branch unreachable. #1

apiKeyEnv now only names the fallback variable — it no longer disables auth.json.

What changed

• src/api-key.ts — new: reads the explabs entry via pi's readStoredCredential(), resolves literals / $VAR / !command (with $$ and $! escapes), and reports which source won
• src/index.ts — passes the unresolved value to pi and uses the resolved one for the model fetch; /login explabs now points at auth.json and EXPLABS_API_KEY
• README.md, CHANGELOG.md — documented both setup options and the precedence

Testing

npm run typecheck, npm test (61 tests) and npm run prettier:check pass.

Also verified end-to-end against a local stub of the /v1/models endpoint, checking the Authorization header pi actually sends:

setup	bearer used
auth.json with !command	resolved from the command
EXPLABS_API_KEY only	env value
both	auth.json wins
auth.json with $VAR / literal	resolved value
nothing configured	no request, provider reported as unconfigured