fix(node): always use paths::data_dir() for I/O, not config.storage.path

THE actual root cause of "binary exits after setup completes" — the
single thread connecting every failure mode in the v0.1.20-v0.1.38
saga.

Node::new at runner.rs:57 was constructing the storage_path from
`config.storage.path`, which defaults to `"./data"` (relative). When
fed to PathBuf::from + create_dir_all, that resolves relative to the
process's cwd:

  - Start menu shortcut launch → cwd = `C:\Program Files\SourceBox
    Sentry CloudNode\` → tries to create `Program Files\...\data\`
    → ERROR_ACCESS_DENIED for non-admin token (UAC-filtered admin
    can't write to Program Files even when in the Administrators
    group). This is what made the binary exit immediately every
    time the user clicked the Start menu shortcut.

  - PowerShell launch from System32 → cwd = `C:\Windows\System32` →
    tries to create `System32\data\` → admin can write so it works
    BUT writes to the wrong location entirely. This is why the user
    had a `C:\Windows\System32\data\node.db` file showing up in
    earlier diagnostic output.

  - cwd = anywhere with a coincidentally-named `data` folder →
    silently writes to the wrong place. (This is what caused the
    Desktop\data pollution from yesterday's debugging.)

The diagnostic finally surfaced today thanks to v0.1.38's
pause-on-error: the user got a clean look at the error message,
then ran the binary as admin from PowerShell which succeeded but
streamed segments to:

  "./data\hls\57db1eac_USB_Webcam\segment_00000.ts"

— relative path, working from System32 cwd. The `./data\` prefix
in that log line was the smoking gun.

Fix: stop trusting `config.storage.path` for I/O. Always use
`crate::paths::data_dir()` which already does correct absolute
resolution (env var → ProgramData on Windows / ./data on
non-Windows). The Node's filesystem layout is now independent of
how the binary was launched.

`config.storage.path` stays in the config struct because it's
exposed in the dashboard's settings page. Updated
`build_settings_info` to surface the actual absolute path
(`paths::data_dir().display().to_string()`) instead of the legacy
config field, so operators see WHERE their data actually lives.

This fixes:
  - The Start-menu-shortcut "binary exits with Access denied"
  - The "ran as admin from PowerShell so it works but writes to
    System32\data" wrong-location problem
  - The whole class of relative-path bugs that paths::data_dir
    was supposed to insulate against but couldn't because Node
    wasn't using paths::data_dir at all

Bumps version to 0.1.39.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Sbussiso

Cargo.lock

@@ -5,7 +5,7 @@
 # should reflect that. Going from `opensentry-cloudnode` to
 # `sourcebox-sentry-cloudnode` keeps the binary name explicit + branded.
 name = "sourcebox-sentry-cloudnode"
-version = "0.1.38"
+version = "0.1.39"
 edition = "2021"
 authors = ["SourceBox LLC"]
 description = "SourceBox Sentry CloudNode — turns a USB webcam into a cloud-connected security camera."

Cargo.toml

@@ -54,7 +54,27 @@ struct RunningStream {
 impl Node {
     pub async fn new(config: Config) -> Result<Self> {
         let api_client = ApiClient::new(&config.cloud.api_url, &config.cloud.api_key)?;
-        let storage_path = PathBuf::from(&config.storage.path);
+        // CRITICAL: ignore `config.storage.path` for I/O. That field
+        // defaults to the relative `./data` and is never overridden in
+        // practice — using it with `PathBuf::from` resolves relative
+        // to cwd, which on a Start-menu-shortcut launch is the
+        // Program Files install dir (read-only for non-admin users)
+        // and on an admin PowerShell launch from System32 is
+        // C:\Windows\System32 (admin can write but it's the wrong
+        // location). Either way, segments / node.db / recordings
+        // end up somewhere unexpected.
+        //
+        // `paths::data_dir()` is the canonical absolute resolver: env
+        // var → platform default (`%ProgramData%\SourceBoxSentry` on
+        // Windows, `./data` on non-Windows where cwd is predictable).
+        // Using it here makes the Node's filesystem layout
+        // independent of how the binary was launched.
+        //
+        // `config.storage.path` is still surfaced via
+        // `build_settings_info` for the dashboard's settings page so
+        // operators see WHERE their data lives — but that's a
+        // display string now, not an I/O path.
+        let storage_path = crate::paths::data_dir();
         std::fs::create_dir_all(&storage_path)?;
         let db = NodeDatabase::new(&storage_path.join("node.db"))?;
         let hls_output_dir = storage_path.join("hls");
@@ -71,7 +91,10 @@ impl Node {
     fn build_settings_info(&self) -> crate::dashboard::SettingsInfo {
         crate::dashboard::SettingsInfo {
             node_name: self.config.node.name.clone(),
-            storage_path: self.config.storage.path.clone(),
+            // Show the actual absolute storage path (where the I/O really
+            // lands) instead of the legacy `config.storage.path` value
+            // (which is now ignored by Node::new).
+            storage_path: crate::paths::data_dir().display().to_string(),
             max_size_gb: self.config.storage.max_size_gb,
             segment_duration: self.config.streaming.hls.segment_duration,
             fps: self.config.streaming.fps,