Add durable randomized local EMA windows

[JacobLinCool]

Summary

Add a random_window intervention trigger that selects randomized EMA/prompt times entirely on the participant device and persists each selection durably.

This extends the occurrence/action foundation in #1. It does not duplicate #4's contextual event rules and does not introduce server triggers, remote scheduling, or arbitrary remote adjustment.

Requirements

Signed trigger model

• Add a bounded random_window trigger to the signed Protocol v1 configuration.
• Define one or more local-time windows and explicit:
  • occurrences per window;
  • maximum per local day;
  • maximum over the study;
  • minimum separation;
  • occurrence availability duration;
  • study/date bounds;
  • behavior when a window is too small to satisfy all constraints.
• Express every duration and local-time component in bounded integer units.
• Specify validation for overlapping windows, impossible separation/count combinations, DST transitions, ambiguous/nonexistent local times, study pause/finish, and configuration size.
• Reuse existing intervention actions and occurrence lifecycle; do not add another notification or survey implementation.

Durable local randomization

• Use a cryptographically secure random generator with unbiased bounded selection.
• Materialize and durably commit an occurrence ID and selected instant before scheduling/posting it.
• Reboot, process death, WorkManager retry, duplicate scheduler execution, and app upgrade must reuse the same committed selection and occurrence ID rather than drawing again.
• Atomically enforce per-window, per-day, total-count, and minimum-separation limits.
• Store only the selection/audit data needed for reproducibility and recovery; never export random-generator internal state or secrets.
• Produce bounded encrypted audit events for selection, suppression, expiry, posting, opening, and deterministic scheduling failure using observable-behavior language.

Clock and time-zone behavior

• Once an occurrence is materialized, wall-clock or time-zone changes must not rewrite its selected instant or occurrence identity.
• Recompute only future, not-yet-materialized local-date windows using the then-current time zone.
• Define exact behavior for a clock jump that makes a selected time late, an ambiguous/nonexistent DST local time, and a time-zone change crossing the local-date boundary.
• Do not claim exact delivery; Android scheduling remains best effort.

Researcher and participant surfaces

• Add Web controls that validate the complete worst case before signing.
• Show researchers minimum/maximum prompts per window/day/study, minimum separation, availability, and worst-case total count.
• Do not precompute or reveal a participant's exact future randomized times in the signed artifact or researcher UI.
• Add clear participant consent copy explaining randomized local prompts and best-effort timing.
• Add no server polling, push commands, remote trigger endpoint, or mutable schedule.

Acceptance criteria

• Statistical/property tests detect modulo bias and confirm selections remain inside configured windows and constraints.
• Process death/reboot before and after persistence, duplicate workers, retries, and app restart never redraw a committed occurrence.
• Count and separation constraints hold atomically under concurrent scheduler execution.
• Materialized occurrences remain stable across clock/time-zone changes; only future unmaterialized windows are recalculated.
• DST gaps/folds, clock jumps, crossed dates, study pause/resume, late execution, finish, and withdraw have deterministic tests.
• Web validation rejects every impossible or unbounded configuration and displays the correct worst-case prompt count.
• Exported lifecycle data can reproduce when and why an occurrence was selected/posted without claiming the participant saw it.
• Network inspection and dependency tests prove that randomization has no server trigger, polling, push-command, or remote-adjustment path.

Documentation

Update the Protocol v1 intervention schema, researcher/participant guides, consent guidance, scheduling/time-zone model, data dictionary, threat model, Web examples, and reproducibility notes.

Dependencies

Blocked by #8 and by the intervention action/occurrence foundation in #1. It is complementary to, but not blocked by or part of, #4.