Add first-class backend switch (--kernel) for Rust runtime integration

[M4n5ter]

Summary

Today, validating the Rust backend from kimi-cli requires tricky test-time overrides (for example setting KIMI_E2E_WIRE_CMD and patching specific e2e paths). This makes local verification and CI setup fragile.

We should add a first-class runtime switch in kimi-cli so Python and Rust backends can be selected explicitly without test-specific hacks.

Problem

• There is no official runtime flag/env to switch kimi-cli to the Rust backend.
• Current Rust integration tests depend on ad-hoc command overrides and local patching.
• This creates friction for contributors and weakens reproducibility in CI.

Proposal

Add backend selection to kimi-cli:

1. CLI flag: --kernel <python|rust>
2. Env var fallback: KIMI_KERNEL=python|rust
3. Optional Rust binary override: KIMI_KERNEL_BIN=/path/to/kimi-agent

Behavior:

• python keeps current behavior (default).
• rust routes runtime startup through wire mode using kimi-agent.
• If --kernel rust is selected but binary is unavailable, return a clear actionable error.

Why this helps

• Removes test-time “tricks” for Rust backend validation.
• Makes Python/Rust parity verification straightforward.
• Enables cleaner CI matrices (same test suite, different backend switch).

Suggested Acceptance Criteria

• kimi --kernel rust runs with the Rust backend in normal workflows.
• KIMI_KERNEL=rust works without CLI flag.
• KIMI_KERNEL_BIN can override binary path for local/dev builds.
• Existing Python backend behavior remains unchanged by default.
• E2E tests can select backend via official flag/env, without patching tests.

Notes

This is primarily a testability and integration ergonomics improvement, but it also provides a clear user-facing control for backend selection.