UX/Privacy: Local work records uploading to cloud without clear user consent feels alarming

### Self Checks

- [x] I have searched for existing issues, including closed ones.
- [x] I confirm that I am using English to submit this report.
- [x] I have not modified this template and filled in all required fields.

### 1. Is this request related to a problem you're experiencing? Tell us your story.

Even after installing and uninstalling the Syncless desktop client many times and building a reasonable level of trust in the product, I experienced a sudden moment of panic when I noticed my **local work records appearing to be sent to the cloud**. My immediate reaction was: "Are my local files being uploaded without my knowledge?"

Upon investigation, the data transfer turned out to be RPC only — it is not persisted to any database. However, the fact that this happens silently, without any explicit opt-in, in-product explanation, or visible consent mechanism, is a serious violation of the user's sense of security and privacy — especially for a developer-facing product where trust is paramount.

The product should never make a user feel like "I have no idea what this client is doing on my machine."

### 2. What is your proposed solution?

**Short-term (UX & transparency):**
- Make this feature **opt-in and disabled by default** for all users.
- When the user enables it, show a clear consent dialog explaining:
> "This feature only establishes an encrypted channel between your personal devices. Data is transmitted via encrypted RPC and is **never persisted** to any server or database."
- Add a persistent, visible indicator (e.g., status bar icon or settings badge) so users always know when this feature is active.

**Long-term (architecture & monetization):**
- Consider positioning this as a **premium upgrade feature**.
- Explore integrating with or referencing **Tailscale-style architecture**: the backend handles only the control plane, the data plane runs through an encrypted peer-to-peer channel, and **device keys are held exclusively by the user**. This would provide cryptographic guarantees that even Syncless cannot access the data in transit.

### 3. Additional context

This issue is not about an actual data breach — the underlying behavior (RPC, no DB persistence) is acceptable. The problem is entirely about **perceived security** and **lack of informed consent**. For a developer-audience product, silent network behavior is a significant trust risk.

Target user persona: developers and power users who are security-conscious and would read network logs, firewall alerts, or proxy traffic — and will immediately lose trust if they see unexpected outbound connections they did not explicitly authorize.

Start by tracing the desktop client's RPC behavior and the settings or controls that enable the feature. Done would require opt-in behavior disabled by default, an explicit consent explanation, and a persistent indicator when the feature is active; the longer-term encrypted peer-to-peer and premium-feature ideas would need separate design decisions.

Written by the indexing model from the issue text.