Add unit tests for telemetry_cmd.rs (follow-up from #1181)

Context

Follow-up from #1181 which added the new rtk telemetry {status|enable|disable|forget} subcommands implementing GDPR consent and erasure flow.

The implementation in src/core/telemetry_cmd.rs (~165 lines) merged without unit tests. Given the sensitivity of the code path (consent management, data erasure, GDPR compliance), this should be addressed before the next release.

Scope

At minimum, the following tests should be added:

maybe_ping() consent guard

• Returns no-op when consent_given is None
• Returns no-op when consent_given is Some(false)
• Only sends when consent_given == Some(true) AND enabled == true

send_erasure_request()

• Includes the X-RTK-Token header when RTK_TELEMETRY_TOKEN is set at compile time
• Returns error on 4xx/5xx HTTP response
• Times out cleanly after 5s
• Handles empty/malformed server response

run_forget()

• Deletes .device_salt if present
• Deletes history.db if present
• Preserves device hash for erasure HTTP call (even after salt deletion)
• Displays full hash (not truncated) in fallback error message
• Works correctly when salt file does not exist (no panic)

prompt_telemetry_consent()

• Returns Ok(()) immediately when consent_given == Some(true) or Some(false) (no re-ask)
• Returns Ok(()) silently when stdin is not a TTY (CI/CD mode) — no prompt output
• Only prompts when consent_given == None AND TTY is interactive

save_telemetry_consent()

• Writes consent_given, consent_date, and enabled atomically
• Preserves other config fields on save

Notes

• Follow the pattern in src/core/tracking.rs::tests for DB fixture setup.
• Use a TempDir for isolation and point RTK_DATA_DIR at it for tests that touch the filesystem.
• Mock HTTP with a simple local server (or use the approach already used elsewhere in the codebase if one exists).

Priority: medium — the code is working correctly (manually verified during #1181 review), but regression risk is high given GDPR implications.