Changelog

The previous guard checked BridgeAuthToken, but that token gets

auto-generated by NativeMessagingRegistrar.EnsureAuthToken() whenever

the bridge binary exists on disk — which it always does in dev builds.

So the check was always true.

Added BridgeEnabled (bool, default false) to AppSettings. The IPC server

now only starts when ApiEnabled || BridgeEnabled. The native messaging

registrar accepts an enableBridge flag to flip the setting when the user

explicitly installs the browser extension.

FindBridgePath() finds the privstack-bridge binary in the build output

directory even in dev builds where the browser extension isn't installed.

This caused the IPC server to always start.

Changed the guard: IPC server now starts only when ApiEnabled is true OR

BridgeAuthToken is non-empty (meaning the browser extension has actually

been paired). The bridge binary existence is still used for native

messaging host registration (writing manifests to browser directories),

which is harmless.

The IPC named-pipe server was starting unconditionally on every launch,

even when neither the browser extension bridge binary is installed nor

the local API is enabled. This wastes a background thread listening on

a pipe nobody will connect to.

Now guarded: IPC server only starts if FindBridgePath() finds the

privstack-bridge binary (meaning the web clipper extension is installed)

OR if appSettings.ApiEnabled is true (local dev API).

Subsystem items now sorted by category (Core → AI → Services → UI →

Runtime → Plugin), then alphabetically within each group. Previously

items appeared in random insertion order.

Intent Engine's consumer task was starting unconditionally in the

constructor even when AI was disabled. The task sat forever on an empty

channel reader, showing a green "active" dot in the Subsystems tab

despite doing no work. Now only starts when AiEnabled && AiIntentEnabled.

IPC Server still shows active — that's correct, it always runs for

browser extension / CLI pipe connections.

The 1-second live metrics timer was calling GetDataMetricsAsync on every

tick regardless of active tab. This triggered ~33 SDK ReadList/Count

calls per second across all plugins (page, task, event, contact, etc.),

saturating the SDK message bus with unnecessary I/O.

• Memory metrics (process-level, no SDK calls) still refresh every 1s
• Data metrics now only run on the Data tab, throttled to every 10s
• Overview tab DataStorageTotal populated on first load only
• Subsystems tab refresh unchanged (local counters, no SDK calls)