Add battery_state.v1 and temporal_context.v1

[JacobLinCool]

Scope narrowed. The Android field-matrix and real-device evidence regime has been
removed from this issue. What remains is the work that a build, a test, or a checked-in
artifact can settle.

Summary

Add two separate, low-rate quality-context collectors: battery_state.v1 and temporal_context.v1.

They share one implementation issue because both help researchers interpret collection quality, but they must remain distinct collector IDs/modules, schemas, configuration controls, disclosures, and Parquet partitions. Neither collector may be used to infer location, travel, presence, or participant behavior.

Requirements

battery_state.v1

• Record a bounded snapshot at collector start and event-driven changes for:
  • battery percentage;
  • charging state;
  • charging source using a strict enum with an explicit unknown value;
  • system power-save mode.
• Use typed fields and units from Create a machine-readable collector and event-schema registry #10, including explicit unavailable/unknown semantics.
• Suppress equivalent consecutive states and enforce a conservative maximum event rate even when the OS emits noisy broadcasts.
• Do not collect battery serial, hardware/device identifiers, voltage, current, charge counter, temperature, health, cycle count, or capacity estimates in this first version.
• Do not claim that charging source or power-save state proves participant intent or device usage.
• Require no new network destination or direct storage access.

temporal_context.v1

• Record a temporal-context snapshot when the study first starts.
• Record event-driven changes when Android reports wall-clock or time-zone changes.
• Include:
  • canonical time-zone ID;
  • UTC offset in an integer physical unit;
  • DST-active state;
  • fixed reason code such as study start, wall-clock changed, time zone changed, or unknown OS signal;
  • the normal Protocol v1 wall/continuous time and boot-session context.
• Do not infer why the change occurred, whether it represents travel, or whether the participant changed it manually.
• De-duplicate equivalent snapshots and apply a strict event-rate bound.
• Define behavior for invalid/unknown zone IDs, ambiguous local times, reboot boundaries, and rapid change bursts.

Product and analysis integration

• Add separate registry entries, compiled Android modules, Web controls, required/optional hardware/access validation, and English/Traditional Chinese consent disclosure.
• Add strict Python decoders, typed Parquet schemas/fixtures, data-dictionary entries, and quality-summary integration.
• Use only the shared collector event sink, clock, lifecycle, and access contracts.
• Pass the assurance gates in Establish enforceable collector assurance gates #11, including long-running, reboot, pause/withdraw, access-state, rate, and storage behaviour.

Acceptance criteria

• Each collector can be configured, disclosed, started, paused, resumed, finished, withdrawn, exported, verified, and materialized independently.
• Initial state is recorded exactly once per valid collector start/recovery transition under the documented lifecycle semantics.
• Duplicate/noisy OS signals cannot exceed registry bounds or produce unbounded identical events.
• Battery fixtures cover charging sources, unknown values, power-save changes, missing properties, and malformed platform input.
• Temporal fixtures cover study start, wall-clock changes, time-zone changes, DST transitions, unknown zones, rapid changes, and reboot/boot-session boundaries.
• Pause/withdraw barriers prevent post-barrier events from entering the research stream.
• Python and Parquet fixtures preserve declared units/types and produce deterministic quality context.
• No event, log, disclosure, or documentation suggests battery state or time zone is proof of activity, location, or travel.

Documentation

Update the collector catalog, researcher and participant guides, consent text, collector implementation guide, data dictionary, threat model, quality-metric definitions, platform matrix, and analysis examples.

Dependencies

Blocked by #10 (schema registry) and #11 (collector assurance gates).