fix(models): use provider options apiKey for discovery and explain fallback (#152) - #161

Fixes #152.

Cause

A key set only in provider.cursor.options.apiKey (README-documented) reached the provider for chat, but model discovery never saw it:

• config hook called discoverModels({}) (env var or cache only)
• provider.models route used only ctx.auth

So the picker showed the 4-model static fallback (src/fallback-models.ts), the exact list in the issue screenshot. Every discovery failure (no key, invalid key, network) also fell back silently: the warning was dropped.

Fix

• config hook passes options.apiKey to discovery; provider.models route also reads provider.key / provider.options.apiKey.
• One toast explaining a fallback. It waits for the auth loader's keyed refresh (or 10s) before deciding, so a stored opencode auth login key that works yields "restart to see all models" instead of a false "no key". If the config key fails but the stored key works, it names the config key. Timers unref'd; skipped under CI.

Not covered (tracked)

• v2 path (src/plugin/v2.ts:345) has the equivalent gap and no notice.
• Config hook and route use different key precedence when both a stored and an options key exist.

Verification

• New test/issue-152-discovery-key.test.ts (12 cases) incl. loader-before-config and bad-config-key/good-stored-key.
• npm run prepublishOnly: 668 tests pass, typecheck + build clean.
• Bun ruled out as a cause: Cursor.models.list() behaves the same under Bun 1.4.1 and Node 26 (both reach Cursor's auth check).
• Not run: a live opencode session with a real key.