A11: MobileDeleteSignal doctype for targeted hard-deletes

[Omprakash-48]

Severity: HIGH
Companion (SDK side): consumer to be filed at dhwani-ris/frappe-mobile-sdk

Problem: When a user's permissions, role, or catchment area changes server-side, there is no signal the SDK can listen for to drop the now-out-of-scope rows from the local DB. The only safe recovery today is to nuke the entire local database and re-sync from scratch.

Impact:

• Massive bandwidth + battery hit every time scope changes (common in field-staff transfers, project rotations).
• User-visible: app appears "broken" while it re-pulls everything.
• Risk window: rows that should no longer be readable remain on the device until the next full re-sync.

Proposed mobile_control work:

1. New doctype Mobile Delete Signal:
   • user (Link → User) — recipient
   • target_doctype (Link → DocType)
   • target_name (Data) — specific docname OR
   • target_filter (Code/JSON) — for bulk scope cuts
   • reason (Select: scope_change | permission_revoked | manual | merge)
   • created_at, consumed_by_devices (Table)
2. Hooks on User, role assignment, and any catchment-defining doctype to enqueue signals on change.
3. Expose signals via the existing meta watermark / pull API:
   • GET /api/method/mobile_control.api.delete_signals?since=<ts>
   • Or piggyback on /syncDetails (see A7).
4. Garbage-collect signals once acknowledged by all of the user's registered devices.

Open questions:

• TTL for unconsumed signals (what if a device never comes back?)
• Should signal consumption be ack'd back to server, or just local watermark?

[Omprakash-48]

SDK companion: dhwani-ris/frappe-mobile-sdk#48