zylos init should accept non-Anthropic API key formats for Claude runtime

[eric-sss89]

Summary

zylos init currently hard-rejects any Claude runtime API key that does not start with sk-ant-. In practice, we expect init to support other API key formats as well, not only Anthropic-style keys.

Problem

During init, the Claude auth path validates --api-key purely by prefix:

• cli/commands/init.js requires opts.apiKey.startsWith('sk-ant-')
• the error shown is: Invalid API key. It should start with "sk-ant-".
• the docs also currently describe --api-key as Anthropic-only in README.md

This means any non-sk-ant- key is rejected before Zylos even tries real validation. For example, keys like sk-cp-... fail immediately.

Reproduction

1. Run zylos init --runtime claude --api-key sk-cp-xxx
2. Observe init fails before any network validation happens
3. Error: Invalid API key. It should start with "sk-ant-".

Expected behavior

If the target runtime is Claude, Zylos should support other API key formats too, rather than assuming all valid keys must start with sk-ant-. As long as the key is not a setup token and the downstream auth check succeeds, init should allow it.

Why this matters

Prefix-only validation is unnecessarily strict and blocks valid deployments that use other key formats. The init flow should validate by actual auth behavior, not by hardcoded vendor-specific prefixes.

Suggested direction

• Keep rejecting setup tokens in the API-key slot (sk-ant-oat...)
• Remove the strict sk-ant- prefix requirement for Claude --api-key
• Allow other key formats to proceed to actual validation
• Update docs/help text so --api-key is not described as Anthropic-only

References

• cli/commands/init.js around the validateInitOptions() API key check
• README.md flag table for --api-key