feat(config): support viper multi-format config loading and CLI confi…

[sky5454]

…g override

• replace json-only load/save with viper-based multi-format support (json/yaml/toml/ini)

• add config path resolution for ~/.picoclaw with extension fallback and explicit --config/-c override

• keep agent model backward compatibility (string/object forms) via decoder hooks

• add regression tests for yaml/json loading, provider api_key decode, and config path resolution

• add config examples and update docs across README translations

📝 Description

🗣️ Type of Change

• 🐞 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 📖 Documentation update
• ⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

• 🤖 Fully AI-generated (100% AI, 0% Human)
• 🛠️ Mostly AI-generated (AI draft, Human verified/modified)
• 👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Related Issue

📚 Technical Context (Skip for Docs)

• Reference URL:
• Reasoning:

🧪 Test Environment

• Hardware: x86 machine
• OS: Windows11
• Model/Provider: GPT5.3-Codex
• Channels:

📸 Evidence (Optional)

Click to view Logs/Screenshots

☑️ Checklist

• My code/docs follow the style of this project.
• I have performed a self-review of my own changes.
• I have updated the documentation accordingly.

[sky5454]

This is the way the command line specifies configuration files for the time being, and it is better for the owner to support better uniform parameter parsing in the future.

[nikolasdehor]

Interesting approach using viper for multi-format config support. A few observations:

Positives:

• The ResolveConfigPath function with extension fallback is well-designed — it tries json/yaml/toml/ini in order.
• The --config/-c CLI flag is a good addition for explicit path override.
• Backward compatibility is maintained via the AgentModelConfig decoder hook that handles both string and object forms.
• Good test coverage: loadconfig_agentmodel_test.go, path_resolution_test.go, viper_config_test.go.
• The build.bat for Windows is a nice bonus.

Concerns:

1. New dependency weight: Adding spf13/viper + go-viper/mapstructure/v2 is a significant dependency addition for a project that aims to be ultra-lightweight (<10MB). Viper pulls in a large transitive dependency tree (pflag, fsnotify, cast, etc.). Has the binary size impact been measured?

2. MarshalJSON removal: The AgentModelConfig.MarshalJSON method was deleted, but SaveConfig still needs to produce valid output. With viper handling the write path, does saving a config that was loaded from YAML produce correct JSON output if the user has a config.json? The format detection in SaveConfig based on filepath.Ext(path) looks correct, but this is worth testing explicitly.

3. INI format limitations: INI does not natively support nested structures or arrays. How does viper handle allow_from lists and nested agents.defaults in INI format? The example file uses flat keys like allow_from=YOUR_USER_ID but the real config expects []string. This might silently produce incorrect config.

4. mapstructure:"model_fallbacks,omitempty": The omitempty tag on mapstructure fields is not standard — mapstructure does not support omitempty. This will be silently ignored but is misleading.

5. Deleted config_test.go tests: 24 lines of tests were deleted. Are the replacement tests in the new test files covering the same cases?

Would like to see the INI array handling tested explicitly before merging.