Align GTK app with Apple home surface

Add the GTK home screen, local account store, daemon gRPC wrapper, and embedded Linux daemon startup path so the Linux app follows the Apple client UX and daemon boundary.

Document the GTK parity expectations and update the daemon IPC and Tailnet BEPs with the cross-platform client model.

evolution/proposals/BEP-0005-daemon-ipc-and-apple-boundary.md

@@ -44,6 +44,7 @@ Burrow should formalize one Apple/runtime boundary: Apple clients speak only to
 - Keeping control-plane I/O out of Swift UI reduces accidental secret, token, and callback sprawl across app code.
 - The daemon boundary makes testing and kill-switch behavior tractable because runtime integration is localized.
 - Apple daemon lifecycle ownership must be explicit: either the app ensures the daemon is running before RPC or the extension owns it and the UI surfaces daemon-unavailable state clearly.
+- Non-Apple presentation clients should follow the same daemon-first lifecycle pattern: connect to a managed daemon when present, or start a user-scoped embedded daemon before issuing RPCs, without adding platform-local control-plane paths.
 
 ## Contributor Playbook
 
@@ -54,6 +55,7 @@ Burrow should formalize one Apple/runtime boundary: Apple clients speak only to
   - daemon unavailable behavior
   - successful RPC path
   - error propagation through the UI
+- Keep Linux GTK and Apple clients visually and functionally aligned around the same daemon-backed home surface: Networks, Accounts, Tunnel, and add flows should remain corresponding views over the daemon API.
 
 ## Alternatives Considered
 
@@ -63,6 +65,7 @@ Burrow should formalize one Apple/runtime boundary: Apple clients speak only to
 ## Impact on Other Work
 
 - Governs the Tailnet refactor and future Apple runtime work.
+- Governs Linux GTK daemon startup parity where the same daemon API is reused from a user-scoped presentation process.
 - Interacts with BEP-0002 control-plane bootstrap and BEP-0003 transport refactoring.
 
 ## Decision

evolution/proposals/BEP-0006-tailnet-authority-first-control-plane.md

@@ -37,6 +37,7 @@ Burrow should treat Tailnet as one protocol family. Tailscale-managed and self-h
   - Burrow-owned authority when explicitly applicable
 - Discovery returns authority and related metadata; editing the authority is the mechanism that moves a configuration from managed default to custom control server.
 - The daemon and control layer own provider inference; the UI should primarily present “Tailnet” plus the selected authority.
+- Platform clients consume the same daemon gRPC surface for Tailnet discovery, authority probing, browser sign-in, and saved network payloads. macOS/iOS SwiftUI and Linux GTK may differ in presentation and local credential stores, but neither should introduce a second control-plane path.
 
 ## Security and Operational Considerations
 
@@ -48,6 +49,7 @@ Burrow should treat Tailnet as one protocol family. Tailscale-managed and self-h
 
 - Remove provider pickers from Tailnet UI unless a concrete protocol difference requires one.
 - Store the authority explicitly in payloads and infer provider internally only when needed.
+- Keep Linux GTK and Apple clients at functional parity by routing Tailnet add/discover/probe/login through `TailnetControl` and `Networks` RPCs instead of platform-local HTTP or legacy JSON daemon commands.
 - Prefer tests that validate authority normalization and discovery behavior over UI-provider branching.
 
 ## Alternatives Considered
@@ -58,7 +60,7 @@ Burrow should treat Tailnet as one protocol family. Tailscale-managed and self-h
 ## Impact on Other Work
 
 - Refines BEP-0002’s Tailscale-shaped control-plane work.
-- Constrains the Tailnet Apple refactor and future daemon control-plane storage.
+- Constrains the Tailnet Apple and Linux GTK refactors plus future daemon control-plane storage.
 
 ## Decision
 
@@ -68,4 +70,5 @@ Pending.
 
 - `burrow/src/control/`
 - `Apple/UI/Networks/`
+- `burrow-gtk/src/`
 - `proto/burrow.proto`