Describe the bug

CLI and Desktop handle "no auth required" custom providers differently. E.g. when creating an Ollama-compatible custom provider via CLI, users can press Enter to skip the API key prompt, which stores an empty string (""). This provider is then accessible in CLI, but Desktop's is_configured logic checks !s.is_empty(), causing these providers to appear "not configured" in the Desktop UI even though they're fully functional.

To Reproduce

1. Run goose configure
2. Select Custom Providers > Add A Custom Provider
3. Choose Ollama Compatible as the API type
4. Enter provider details, and press Enter to skip the API key prompt (leaving it empty)
5. Complete the setup
6. Open goose Desktop > Settings > Models > Configure providers
7. Observe that the custom provider does not have a green checkmark and appears "not configured", which means it won't show up in the providers list for selection

Expected behavior
Custom providers with empty API keys (valid for local/no-auth endpoints) should show as "configured" in Desktop if they were successfully created via CLI.

Screenshots
N/A

Please provide the following information

• OS & Arch: macOS
• Interface: CLI to create, UI to observe
• Version: v1.16.0
• Extensions enabled: N/A
• Provider & Model: Custom Ollama-compatible provider

Additional context
The issue appears to be in Desktop's is_configured logic, which checks !s.is_empty() for the API key. An empty string ("") is stored in the keychain when the user skips the prompt, which fails this check.

Possible solutions:

• CLI could store a placeholder value (e.g., "notrequired" like Desktop does) instead of empty string
• Desktop could treat empty string as valid for Ollama-compatible providers
• Align on a convention for "no auth required" across both interfaces