fix(json): tolerate raw control chars in strings instead of dropping output

[dosthcpp]

Summary

• rtk json (and pipes like curl … | rtk json) used strict serde_json::from_str, which rejects unescaped control characters (U+0000–U+001F) inside string values per RFC 8259 §7. Some real-world producers emit them anyway (e.g. an API echoing a user-supplied newline into a field). rtk then printed nothing and exited 1, losing the whole payload and forcing a raw re-fetch — net-negative for a token-saving tool and contrary to the Never Block principle.
• Adds parse_json_lenient: strict parse first (fast path, zero behavior change for valid JSON), and only on failure retry once with raw in-string control chars rewritten to their equivalent \uXXXX escapes via a string-aware scanner. Whitespace between tokens and already-escaped sequences stay byte-for-byte identical; genuinely malformed input still surfaces the original strict error.

Before / After

$ printf '{"body":"line1\nline2"}' | rtk json -      # raw newline inside the string
# before:  rtk: Failed to parse JSON: control character (...)   (exit 1, 0 bytes stdout)
# after:   { body: "line1
#           line2" }                                            (exit 0)

Test plan

• cargo test json_cmd — 19 passed, 0 failed (9 new + 10 existing). New tests cover recovery in compact and schema modes, control char in keys, fast-path borrow, whitespace preservation, existing-escape preservation, and malformed-still-errors.
• cargo fmt -- --check src/cmds/system/json_cmd.rs — clean
• cargo clippy --lib — no new warnings on the changed file
• Manual: printf '{"id":"abc","body":"a\nb"}' | rtk json - now renders the payload (exit 0); printf '{not json' | rtk json - still errors (exit 1); valid JSON output unchanged.

Targets develop per CONTRIBUTING.md.

[CLAassistant]

All committers have signed the CLA.