[feat] Add customer config path support

[carzygod]

📝 Description

Add customer config path support for command agent and gateway

It support :

./picoclaw-linux-amd64 agent  -c ./config.json -m "hi,who are you ?"

And

./picoclaw-linux-amd64 gateway -c ./config.json

Allows users to set their configs via command , which will makes it easier to host multi-picoclaw-agent on one compute env .

🗣️ 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

NA

📚 Technical Context (Skip for Docs)

NA

🧪 Test Environment

• Hardware: PC
• OS: Ubuntu 22.04 amd64
• Model/Provider: deepseak-chat
• Channels: Telegram

📸 Evidence (Optional)

Click to view Logs/Screenshots

NA

☑️ 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.

[xiaket]

Sorry with #429 merged in, this needs a rebase/refactor.

Also it's customised, not customer.

[yinwm]

Sorry with #429 merged in, this needs a rebase/refactor.

Also it's customised, not customer.

should close this?

[xiaket]

should close this?

@yinwm this feature is not covered in #429. We don't have the capability to specify the -c flag for agent/gateway. So I would say it is still of value.

[nikolasdehor]

Useful feature for multi-instance deployments. The approach is straightforward. A few issues:

1. No validation that the config file exists before loading.
If the user passes -c /nonexistent/path.json, config.LoadConfig will return the default config (since it treats os.IsNotExist as "use defaults"). This is confusing -- if the user explicitly passes a path, a missing file should be a hard error, not a silent fallback. Consider adding an os.Stat check in loadConfigFromPath when path is explicitly provided.

2. Duplicated argument parsing logic.
The -c/--config parsing is copy-pasted between cmd_agent.go and cmd_gateway.go with subtle differences (agent has --config= handling inside a default: case, gateway has it as separate if blocks). This should be extracted into a shared helper in main.go to keep it DRY and avoid divergence over time.

3. status and other subcommands are not updated.
The status command (and potentially others like configure) still uses loadConfig(). If a user runs multiple instances with -c, they would expect picoclaw status -c ./config.json to work too. Worth mentioning in the PR description whether this is intentional or planned for a follow-up.

4. The --config= form silently ignores unknown flags.
In the agent command, the default: case only checks for --config= and -c= prefixes. Any other unknown flag is silently ignored. This could mask typos (e.g. --conifg=foo.json).