Specify a signed desired-state policy protocol with replay protection

[ShalomMaman]

Parent epic: #41

Goal

Define the only remote policy protocol the device may accept. Prefer a device-pulled, signed latest desired state over an arbitrary queue of imperative commands.

Protocol requirements

Each policy envelope must be schema-validated and include enough authenticated context to enforce at least:

• target device or fleet binding;
• schema and policy version;
• monotonically increasing policy revision;
• current authorization epoch;
• issue time, bounded expiry and key identifier;
• canonical policy digest and signature;
• explicit compatibility requirements where needed.

The device authenticates the service transport and independently verifies the envelope before it reaches Android policy code. Stale, replayed, expired, wrongly targeted, wrongly signed, unsupported or malformed revisions are rejected without replacing the current verified policy.

Required behavior

• Last-known-good / fail-stable: offline operation, service failure, expired authentication or an invalid revision leaves the last verified policy active. Do not describe this as automatically tightening or locking the device.
• No stale command queue: reconnecting must reconcile to the current authorized desired state; an old queued actor request cannot become effective later.
• Serialized enforcement: accepted changes enter the existing PolicyReconciliationCoordinator/policy engine and use Android read-back verification. There is no second enforcement path.
• Truthful status: distinguish requested, downloaded, accepted, applying, verified, rejected, failed and superseded states. Never report success before read-back verification.
• Deterministic conflicts: specify precedence for local emergency recovery, maintenance windows, active kiosk state, pending remote policy and local owner actions.
• Time and reboot safety: define bounded clock skew, reboot persistence, retries, interrupted reconciliation and key rotation.

A push service may wake the device to check for a newer revision, but the notification is not the authority or policy payload.

Acceptance criteria

• A canonical schema and signing format are versioned and documented.
• Device/fleet binding, monotonic revision, authorization epoch, expiry and replay protection are mandatory.
• Last-known-good behavior is proven for offline, invalid and unavailable-service cases.
• Remote policy uses the existing serialized, read-back-verified policy engine.
• Conflict and supersession rules are deterministic and testable.
• Key rotation and rollback-by-roll-forward are supported without accepting downgrade revisions.
• The protocol cannot express arbitrary shell execution or an unbounded general-purpose command channel.

Non-goals

• Remote shell, arbitrary intents or covert control.
• Treating FCM or another push transport as an authorization mechanism.

Hebrew summary

המכשיר ימשוך את המדיניות הרצויה והעדכנית בלבד, יאמת חתימה, יעד, גרסה ותוקף, ורק אז יעביר אותה למנוע המדיניות הקיים. מדיניות ישנה, משוכפלת או לא תקינה נדחית והמדיניות הבטוחה האחרונה נשארת פעילה.