feat(plugin): expose logging API to plugins

[jamesmurdza]

Issue for this PR

Closes #27285

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Plugins currently have no way to write to OpenCode's log files — they can only use console.log, which isn't captured anywhere useful.

This adds a log object to the PluginInput that every plugin receives, with debug, info, warn, and error methods. Each plugin gets its own logger namespaced as plugin.<id>, so its output is written to OpenCode's normal log files and is attributable to the specific plugin.

How it works:

• packages/plugin/src/index.ts — adds the public PluginLogger type and a log: PluginLogger field on PluginInput.
• packages/opencode/src/plugin/index.ts — builds a per-plugin logger via Log.create({ service: "plugin.<id>" }) and injects it when each plugin loads. The <id> is the package name for installed plugins, or the file basename for file:// plugins (e.g. …/my-plugin/index.ts → my-plugin, …/my-plugin.ts → my-plugin).

Since log is now a required field on PluginInput, the existing plugin auth-test fixtures are updated to supply it.

How did you verify your code works?

Manually, by running the real CLI with a plugin and confirming its log output appears, correctly namespaced. Minimal repro:

1. Create myplugin.ts anywhere:

   export default async ({ log }) => {
     log.debug("debug line", { ok: true })
     log.info("info line")
     log.warn("warn line")
     log.error("error line")
     return {}
   }

2. In any project, point opencode.json at it (use the absolute path):

   {
     "$schema": "https://opencode.ai/config.json",
     "plugin": ["file:///absolute/path/to/myplugin.ts"]
   }

3. Run any command that boots the project, with logs printed to the terminal:

   opencode models --print-logs --log-level DEBUG
   

4. Confirm the output contains the plugin's lines, namespaced service=plugin.myplugin:

   DEBUG … service=plugin.myplugin ok=true debug line
   INFO  … service=plugin.myplugin info line
   WARN  … service=plugin.myplugin warn line
   ERROR … service=plugin.myplugin error line
   

This confirms the log object is injected, all four levels are written, and the plugin.<basename> namespace is derived correctly. Re-running with --log-level INFO drops the DEBUG line, confirming level filtering flows through the plugin logger.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR