Add one-step "export + send to support" command instead of manual two-step flow

What's the problem?

When an error happens (e.g. a rate-limit 429), kimi-cli tells the user to export their session and then separately send the exported file to support:

LLM provider error: Error code: 429 - {'error': {'message': 'Your account org-... / proj-... <ak-...>
request reached organization TPD rate limit, current: 1500246, limit: 1500000',
'type': 'rate_limit_reached_error'}}
If this persists, run kimi export and send the exported data to support for assistance.
Please do not share the exported file publicly.

This is a two-step manual flow:

1. Run kimi export → get a file on disk.
2. Figure out which support channel to use, attach the file, write an email/issue, send it.

In practice most users won't do step 2 at all, and when they do, the support team gets reports without consistent metadata (CLI version, OS, model, redacted token IDs, error code, etc.).

Suggested fix

Collapse this into one command that exports and submits in a single step, e.g.:

kimi report            # export + submit, with confirmation prompt
kimi report --dry-run  # just produce the file, don't send

Behavior:

• Bundles the same data kimi export produces today, plus structured diagnostic metadata (CLI version, OS, Python/uv version, model, last error, redacted org/proj/key IDs).
• Shows the user a summary of what's about to be sent and asks for explicit confirmation before uploading.
• Uploads to an official Moonshot support endpoint over HTTPS and returns a ticket / report ID the user can quote.
• Falls back gracefully (prints the local file path + support email) if the upload endpoint is unreachable.
• The existing kimi export command stays as-is for users who want the file only.

It might also make sense to surface this directly from the error message:

If this persists, run `kimi report` to send a diagnostic bundle to support (one step, with your consent).

Why it matters

• Removes a friction step that today silently drops most error reports on the floor.
• Guarantees support receives a consistent, well-structured bundle instead of ad-hoc attachments.
• Keeps user trust: the upload is opt-in, shows a preview, and returns a ticket ID — it is not silent telemetry.
• Aligns with how most modern CLIs handle crash reporting (gh, rustup, vercel, etc.).

Open questions

• Should the upload include the full conversation transcript by default, or require an extra --include-transcript flag for privacy?
• What's the right default redaction policy for API keys / org IDs / file paths in the bundle?
• Should kimi report also be auto-suggested (not auto-run) after repeated errors of the same type?

Start by reading the existing kimi export flow and the error message that currently directs users to it; no implementation files or tests are named in the issue. Done means a consent-based kimi report flow is specified with dry-run behavior, diagnostic metadata and redaction, an upload result or local fallback, while kimi export remains unchanged.