Refactor provider resolution, add Zen provider, and gateway service install

[euhenriquecosta]

Summary

This PR refactors provider selection to a registry-based flow, integrates the Zen provider, hardens provider resolution rules, and adds an automated systemd installer command for the gateway.

Problem

Provider creation was centralized in a large monolithic factory with duplicated condition branches and broad model matching heuristics. This increased change risk for each new provider and could route to the wrong backend in production. Gateway service installation was also fully manual.

Root Cause

• Provider resolution logic was spread across explicit provider branches and model-name fallbacks in one function.
• Matching relied on ambiguous string checks, which could misclassify models.
• No first-class CLI flow existed to install and enable the gateway as a Linux service.

Changes

• Replaced monolithic provider selection with a registry-based resolver.
• Added self-registration for built-in providers.
• Added Zen provider registration and config support.
• Hardened resolution behavior:
  • explicit provider now fails fast for unknown/unconfigured provider
  • model prefix matching tightened to reduce ambiguous auto-selection
  • removed unsafe Zen opencode/ auto-prefix route
• Kept CreateProvider as a single delegated call to the registry.
• Added picoclaw gateway install:
  • validates Linux + root + systemctl
  • writes /etc/systemd/system/picoclaw.service
  • runs daemon-reload + enable --now
• Updated CLI help text for gateway command.
• Updated example config with providers.zen.

User Impact

• Adding providers is now lower-risk and simpler.
• Production behavior is safer: explicit provider config errors are surfaced immediately.
• Zen usage is supported with explicit provider configuration and real model IDs.
• Gateway deployment on VPS is faster with one command.

Validation

• go test ./pkg/providers
• go test ./...
• Live Zen integration checks:
  • direct /models and /chat/completions with a -free model
  • end-to-end picoclaw agent -m ... with provider=zen and model=kimi-k2.5-free

[Leeaandrob]

@Zepan This PR refactors provider resolution and adds a Zen provider. However, PR #213 (Provider Refactor by Protocol — roadmap #283) is a more comprehensive approach to the same problem and is already In Progress on the board.

Recommendation: Close in favor of #213. The provider refactor in #213 supersedes this approach. The Zen provider can be added as a follow-up after #213 lands.

[Leeaandrob]

@euhenriquecosta take look my comments.

[yinwm]

Closure Notice

Thank you for this contribution! However, I'm going to close this PR in favor of #213 (Refactor providers by protocol family).

Reason

PR #213 implements a more comprehensive approach to provider refactoring based on Discussion #122 and Issue #283. It:

1. Separates providers by protocol family (OpenAI-compatible, Anthropic, etc.) rather than by vendor
2. Creates dedicated packages (pkg/providers/openai_compat/, pkg/providers/anthropic/)
3. Provides a cleaner foundation for adding new providers via configuration

What happens to the Zen provider?

The Zen provider can be added as a follow-up after #213 lands. Since Zen uses an OpenAI-compatible protocol, it would become a simple configuration entry in the new architecture:

providers:
  openai_compatible:
    instances:
      zen:
        api_base: https://api.zen.ai/v1
        api_key: xxx

Next Steps

1. Merge Refactor providers by protocol family (discussion #122) #213 as Phase 1
2. Implement Phase 2 (explicit api_type config)
3. Add Zen as a config-based OpenAI-compatible provider

I appreciate the effort put into this PR, especially the registry-based approach and the gateway service install feature. Those ideas may still be valuable for future iterations.

cc: @Leeaandrob

[Leeaandrob]

Please open another pr just adding the Zen as provider. We are merge the #213 with the focus in to have a standard and package for providers. @euhenriquecosta