feat(llm): add local OpenCode CLI provider with dynamic model discovery

Problem

MoneyPrinterTurbo currently supports many API-based LLM providers and local runtimes, but it does not have a built-in way to use the models and provider accounts already configured in a user's local OpenCode installation.

Users who already use OpenCode may want to generate video scripts and search terms through their existing OpenCode setup without copying API keys or maintaining a second model list in MoneyPrinterTurbo.

Proposed solution

Add a focused OpenCode CLI LLM provider for the existing script and keyword-generation workflow.

The provider would:

1. Detect the locally installed opencode executable, with an optional configurable CLI path.
2. Ask OpenCode for the models available in the current OpenCode environment.
3. Show the enabled, text-capable models in the WebUI, grouped by provider and including available variants where applicable.
4. Save the selected OpenCode model reference.
5. Send the existing MoneyPrinterTurbo prompt to OpenCode for stateless text generation.
6. Pass the returned text through the existing response normalization, retry, and error-handling paths.

OpenCode should remain responsible for authentication, provider configuration, credentials, and model availability. MoneyPrinterTurbo should not import, copy, or persist OpenCode credentials.

Proposed user flow

1. Select OpenCode CLI under LLM Provider.
2. Confirm or select the OpenCode executable path if it is not found on PATH.
3. Refresh/load the available OpenCode models.
4. Select a model such as an OpenCode Free, Zen, Go, or other configured provider model when available.
5. Use Test LLM Connection and generate a script normally.

The model list should be discovered dynamically rather than hard-coding OpenCode Free/Zen/Go model IDs. The implementation should preserve the full OpenCode provider/model reference, including an optional variant.

Technical direction

The preferred integration is the documented OpenCode V2 CLI/API surface, using structured model discovery and stateless generation rather than parsing human-readable terminal output. The current OpenCode API exposes model discovery and a one-shot text-generation route; the implementation should isolate these calls behind a provider adapter and define a minimum supported CLI version.

The provider should not run a full coding-agent session for ordinary script generation. MoneyPrinterTurbo only needs a prompt-to-text response, and disabling tool execution avoids unintended file, shell, MCP, or plugin activity.

Safety and compatibility

• Do not store or log OpenCode credentials.
• Do not pass user prompts through an unrestricted agent session.
• Use argument-safe subprocess invocation and bounded timeouts.
• Provide distinct errors for a missing CLI, unauthenticated CLI, unavailable model, old/incompatible CLI, empty model catalog, and generation failure.
• Cache model discovery long enough to avoid running an external process on every Streamlit rerender, while still providing a manual refresh action.
• Document that Docker users need an OpenCode executable and credentials available inside the container; a host-only installation is not automatically visible.
• Add mocked unit/UI tests so CI does not require OpenCode to be installed.

Non-goals

This proposal is limited to using OpenCode for MoneyPrinterTurbo's existing LLM text-generation workflow. It does not propose exposing arbitrary OpenCode agents, tools, file access, MCP servers, or OpenCode sessions to the WebUI.

Acceptance criteria

• OpenCode CLI appears as a selectable LLM provider.
• The provider can discover the user's currently available OpenCode models.
• The WebUI allows selecting a model and reports discovery/generation errors clearly.
• A successful connection test and normal script/keyword generation work through the selected model.
• No OpenCode credentials are copied into MoneyPrinterTurbo configuration.
• Automated tests cover discovery, selection, generation, and failure paths.
• Documentation describes prerequisites, supported behavior, and limitations.

Related prior attempt

PR #1142 previously explored OpenCode Go support. It was closed after becoming stale and combining provider work with unrelated changes; this proposal is intentionally a separate, focused design for the local OpenCode CLI and dynamic model discovery.

References

• OpenCode V2 CLI: https://opencode.ai/v2/docs/cli
• OpenCode V2 commands: https://opencode.ai/v2/docs/cli/commands
• OpenCode V2 API: https://opencode.ai/v2/docs/api
• OpenCode V2 models: https://opencode.ai/v2/docs/models