docs: cover the models-info plugin and oauth2 bearer propagation

[stephane-segning]

Summary

The workspace became a two-plugin repo with #18, but the top-level README.md and docs/ still only described @vymalo/opencode-oauth2. This fills the gap. Docs-only — no code or behavior change.

What changed

• docs/models-info.md (new) — adopter-depth guide for @vymalo/opencode-models-info: the single config hook, the auth-composition matrix (including the oauth2 bearer propagation), URL resolution, caching + failure modes, and the full log-event reference. Links the package README for the exhaustive config reference instead of duplicating it.
• README.md — @vymalo/opencode-models-info added to the Workspace Layout and Documentation tables, plus a new "Companion plugin: model metadata" section with a combined oauth2 + models-info opencode.json example.
• docs/architecture.md — a note up top that a second plugin exists, the new config-time Authorization propagation documented as step 6 of the config hook (the sole, one-directional coupling point between the two plugins), and the two oauth2_bearer_* events added to the event-name table.

Notes for the reviewer

• All new cross-links verified to resolve (files + the #config--plugin-load anchor exist).
• Markdown only, which Biome ignores, so format:check/lint are unaffected (still 62 files clean).

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces documentation and configuration details for the new companion plugin @vymalo/opencode-models-info, which enriches model metadata from an OpenRouter-shaped endpoint. It also details how the existing @vymalo/opencode-oauth2 plugin propagates cached bearer tokens to allow seamless authentication. The review feedback suggests improving documentation clarity by explicitly naming the plugins in the README to avoid ambiguity, and correcting the merge strategy terminology in the models-info documentation from 'upstream-wins' to 'existing-wins' to accurately reflect that local configurations take precedence.

[gemini-code-assist]

In this workspace-level README.md, using the phrase "this plugin" twice in a section dedicated to the companion plugin (@vymalo/opencode-models-info) is ambiguous and confusing. It can easily lead readers to believe that the companion plugin is the one performing the token stamping, whereas it is actually @vymalo/opencode-oauth2 that does so. Specifying the plugin names explicitly resolves this ambiguity.

Suggested change

It doesn't depend on this plugin: it runs as a `config` hook *after* other plugins, so it composes with oauth2, static API keys, or no auth at all. When paired with `@vymalo/opencode-oauth2` ≥ 0.4.0, OAuth2-protected metadata endpoints work with zero extra config — this plugin stamps the cached bearer onto the provider's headers at config time, and the metadata fetch inherits it.

It doesn't depend on `@vymalo/opencode-oauth2`: it runs as a `config` hook *after* other plugins, so it composes with oauth2, static API keys, or no auth at all. When paired with `@vymalo/opencode-oauth2` ≥ 0.4.0, OAuth2-protected metadata endpoints work with zero extra config — the oauth2 plugin stamps the cached bearer onto the provider's headers at config time, and the metadata fetch inherits it.

[gemini-code-assist]

The term upstream-wins is contradictory here. In network and API contexts, "upstream" refers to the remote server/API. Since the behavior described is that "any field already set on the model entry is never overwritten" (meaning the local/existing configuration takes precedence over the fetched remote metadata), this is actually an existing-wins or local-wins merge strategy. Using "upstream-wins" will confuse readers into thinking the remote API's values will overwrite their local overrides.

Suggested change

	4. **Merges** derived metadata onto each model whose `id` (or declared `id`) matches an entry in the catalog. The merge is **upstream-wins**: any field already set on the model entry is never overwritten. Running the hook twice is a no-op.
	4. **Merges** derived metadata onto each model whose `id` (or declared `id`) matches an entry in the catalog. The merge is **existing-wins** (or **local-wins**): any field already set on the model entry is never overwritten. Running the hook twice is a no-op.