Changelog

Switch the language pill click handler from PointerReleased to

PointerPressed. When the AvaloniaEdit TextEditor has focus, it captures

the pointer on press, preventing PointerReleased from reaching the

pill overlay. PointerPressed always fires on the element under the

cursor regardless of capture state.

Email: +4 intents (search_email, mark_read, move_message, reply) — 5 total

• search_email: search by subject/sender with folder filter
• mark_read: mark messages read/unread by ID or subject search
• move_message: move to folder (trash/archive/junk/custom)
• reply: create reply draft (saves as draft, does not send)

Journal: +2 intents (search_entries, delete_entry) — 3 total

• search_entries: search by content with date/mood filters
• delete_entry: delete by ID or date search

Habits: +3 intents (update_habit, get_streak, get_today_status) — 6 total

• update_habit: modify name, frequency, target, category, active status
• get_streak: returns current/best streak and completion rate
• get_today_status: checklist of today's logged/pending habits

All plugins use ResolveEntityAsync pattern with ID-first/search-fallback.

Email uses `with` expressions for init-only record properties.

After wiping local data and purging the cloud workspace, stale cursor

state in the local cloud_sync_cursors table caused the sync engine to

re-upload entities that plugins recreate on startup. The server-side

purge cleared S3 batches and API cursors, but the local DuckDB cursor

table was never cleared — so when sync restarted and PushAllEntities()

ran, the engine treated the re-created entities as new changes.

Adds privstack_cloudsync_clear_cursors FFI export that calls the

existing EntityStore::clear_cloud_cursors() method, wires it through

NativeLibrary → ICloudSyncService → CloudSyncService, and calls it

in SeedDataService.PurgeCloudWorkspaceIfConnectedAsync() immediately

after the server-side purge succeeds.

Calendar: +3 intents (update_event, delete_event, list_events) — 4 total

• update_event: modify title, time, location, description, status, all-day
• delete_event: delete by ID or title search
• list_events: query events by date range (default next 7 days)

Notes: +3 intents (search_notes, create_sticky, delete_note) — 4 total

• search_notes: search pages by query, returns wiki-link summary
• create_sticky: create quick sticky note with color
• delete_note: trash page by ID or title search

Contacts: +4 intents (update_contact, search_contacts, create_company,

log_interaction) — 5 total

• update_contact: modify any contact field by ID/name search
• search_contacts: search contacts, returns wiki-link summary
• create_company: create company record with industry/website
• log_interaction: log call/email/meeting/note with a contact

All three plugins follow the Tasks gold-standard pattern with

ResolveEntityAsync helpers for ID-first/title-fallback resolution.

When the user wipes data (Wipe, Reseed, or Reset Data on unlock screen),

the local DuckDB cursors are destroyed but the server-side sync_batches

and sync_cursors remain. On next sync startup the device's cursor resets

to 0, causing getPendingChanges to report the device's own old batches

as pending — triggering an infinite download loop of stale data every

poll cycle.

Fix: call the server's /api/cloud/workspace/purge endpoint before wiping

local data. This clears batches, cursors, snapshots, blobs, and S3

objects server-side so the sync engine starts clean.

• SeedDataService: add PurgeCloudWorkspaceIfConnectedAsync() as step 0

in WipeAllPluginDataAsync (covers both Wipe and Reseed paths)

• SetupWizardViewModel: add PurgeCloudWorkspaceAsync() before runtime

shutdown in ConfirmResetData (covers unlock screen Reset Data)

• Both methods are best-effort — cloud purge failure doesn't block

local wipe