Module consent 

Persisted user consent for telemetry collection.

Backs the v0.4 rtb-cli telemetry status / enable / disable / reset subtree. The file lives at <config_dir>/<tool>/consent.toml:

version = 1
state = "enabled"   # or "disabled" or "unset"
decided_at = "2026-05-08T12:34:56Z"

Application::builder().read_telemetry_consent() (in rtb-cli) threads the resulting CollectionPolicy into the crate::TelemetryContext it builds.

Why a separate file (not inside config.yaml)?

The v0.4 scope addendum (§2.5, O3 resolution) keeps consent in a dedicated file so:

• The state is unambiguously CLI-managed; config.yaml stays a user-edited artefact.
• telemetry reset can unlink(2) rather than rewrite YAML.
• The schema is versioned independently, so a future consent format change doesn’t force a config-file migration.

Structs

Consent

On-disk consent record. Version-tagged so a future schema change is non-breaking.

Enums

ConsentState

User-recorded consent state. Maps onto CollectionPolicy via From: Enabled → Enabled; Disabled and Unset both → Disabled (opt-in is the default).

Functions

read

Read the consent file. Ok(None) when the file does not exist — callers should treat that as ConsentState::Unset.

reset

Convenience: delete the consent file. Ok(()) if the file was already absent — telemetry reset is idempotent.

write

Write the consent file. Parent directories are created on demand. The write is not atomic at v0.4 — callers concerned about torn writes implement their own staging on top.