Implement a minimal consent-based remote application-policy pilot

[ShalomMaman]

Parent epic: #41

Dependencies: #43, #44, #45, #46, #47 and #48. The read-only path must be proven before this issue enables writes.

Goal

Validate the focused Device Guard use case with the smallest safe remote-write surface: delegated application filtering and explicitly approved low-risk presets.

Initial allowed scope

• Allow or block ordinary user applications through the existing reviewed package-policy model.
• Apply a small, enumerated set of low-risk system-policy presets only after their recovery behavior is proven.
• Show impact before submission and require explicit confirmation.
• Allow the account owner/device custodian to withdraw delegated access and pause remote management.
• Produce one signed desired-policy revision, have the device pull and verify it, apply it through the existing serialized reconciliation engine, read Android state back, and report the verified outcome.

Explicitly excluded from the first pilot

• Kiosk activation, exit or target changes.
• Developer options, ADB or USB changes.
• Network, VPN, account or store changes that could disconnect or lock out recovery.
• Ownership transfer, account recovery or local recovery-code operations.
• Raw system-package editing or acceptance of unknown OEM risk.
• Arbitrary commands, intents, scripts or remote shell.

Any excluded capability requires a separate reviewed expansion issue with physical recovery evidence and recent strong authentication.

Safety requirements

• The delegated administrator never receives the local PIN or recovery code.
• Every write is authorized server-side, bound to the current authorization epoch, audited and signed.
• The device retains last-known-good policy when offline or when a revision is invalid.
• Requested, accepted, applying, verified, rejected, failed and superseded states are distinguishable.
• A remote change cannot bypass local emergency recovery, maintenance or kiosk conflict rules.
• The owner sees who requested the change and its verified result.

Acceptance criteria

• The first pilot exposes only application allow/block and an approved low-risk preset list.
• Every accepted revision passes signature, target, schema, monotonic revision, authorization-epoch and expiry checks.
• Enforcement uses the existing single policy queue and Android read-back verification.
• Revoked administrators and stale sessions cannot issue or resurrect changes.
• Offline and failed-device states never appear as successful.
• Lockout-prone controls are technically absent, not merely hidden in the UI.
• No unresolved P0/P1 security finding remains before pilot enrollment.

Non-goals

• General-purpose EMM functionality.
• Remote recovery replacing the proven local recovery path.

Hebrew summary

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