fix(paths): legacy ./data check requires node.db, not just dir existence

The "binary exits after setup" / "asks me to set up FFmpeg again" bug
the user has been hitting since at least v0.1.31 traces back to a
single-line footgun in `paths::data_dir()`:

  let legacy = PathBuf::from("./data");
  if legacy.exists() {
      return legacy;
  }

The intent was to honour cargo-build dev workflows where the binary
is launched from a repo root that has ./data with the developer's
config — keeping the next launch from silently moving to ProgramData
and orphaning their data.

The bug: this picks up ANY directory named "data" in the launch cwd.
For MSI users testing from a `cmd /c <script>.bat` on their Desktop
where they happen to have a "data" folder (from some other project,
or auto-created during an earlier confused invocation), data_dir
resolves to:

  C:\Users\<x>\Desktop\data

instead of the actual install:

  C:\ProgramData\SourceBoxSentry

Cascade:
  - Config::load reads Desktop\data\node.db → doesn't exist →
    needs_setup=true, wizard re-runs every launch.
  - find_tool looks for ffmpeg at Desktop\data\ffmpeg\bin\ffmpeg.exe
    → doesn't exist → falls through to bare "ffmpeg" → PATH search
    fails → "Io error: program not found", binary exits.
  - Meanwhile the REAL data is at C:\ProgramData\SourceBoxSentry
    with node.db (40 KB) + ffmpeg/ (200 MB of ffmpeg.exe + ffprobe.exe)
    all present; the binary just ignores it.

Diagnosed via the user's PowerShell test today which confirmed
`Test-Path "C:\ProgramData\SourceBoxSentry\ffmpeg\bin\ffmpeg.exe"`
returns True — the file is exactly where we expect, the binary
just isn't looking there.

Fix: require `./data/node.db` to exist, not just `./data/`. Anchors
the legacy check to actual CloudNode state instead of any
coincidentally-named directory in the cwd.

  - Cargo-build dev with valid `./data/node.db`: legacy check
    succeeds → returns `./data` → existing dev workflow unchanged.
  - Cargo-build dev with empty `./data` (rare; only happens if you
    manually rm the contents): legacy check fails → falls through to
    platform default → user gets fresh setup, no data lost (there
    wasn't any).
  - MSI install with random `Desktop\data`, `Desktop\data` containing
    unrelated files, etc.: legacy check fails → falls through to
    `C:\ProgramData\SourceBoxSentry` → finds the install.
  - MSI install with cwd = `C:\Program Files\SourceBox Sentry CloudNode\`
    (no `data` subdir): legacy check fails → ProgramData → works.

This is the actual long-term fix the user has been asking for: MSI
install + clicking the Start menu shortcut → camera dashboard with
streaming. No PowerShell, no terminal commands, no setup re-prompts.

Bumps version to 0.1.34.

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.33"
+version = "0.1.34"
 edition = "2021"
 authors = ["SourceBox LLC"]
 description = "SourceBox Sentry CloudNode — turns a USB webcam into a cloud-connected security camera."

Cargo.toml

@@ -58,10 +58,37 @@ pub fn data_dir() -> PathBuf {
     }
 
     // 2. Legacy in-place ./data/ takes priority over the platform
-    //    default so existing installs don't migrate themselves on the
-    //    next launch (which would silently abandon their config DB).
+    //    default so existing cargo-build installs don't migrate
+    //    themselves on the next launch (which would silently abandon
+    //    their config DB).
+    //
+    //    CRITICAL: this check requires `./data/node.db` to exist, NOT
+    //    just `./data/`. Original logic checked only `./data` existence
+    //    which produced a footgun for MSI users:
+    //
+    //      - User puts the test .bat or any random binary on their
+    //        Desktop where they happen to have a folder named "data"
+    //        (from some other project, or auto-created by an earlier
+    //        confused invocation, or whatever).
+    //      - cwd at launch = Desktop. `./data` resolves to
+    //        `C:\Users\<x>\Desktop\data` and exists.
+    //      - data_dir returns `./data`. Config::load reads
+    //        `./data/node.db` — doesn't exist — needs_setup=true,
+    //        wizard re-runs.
+    //      - find_tool looks for ffmpeg at `./data/ffmpeg/bin/ffmpeg.exe`
+    //        — doesn't exist — falls through to bare "ffmpeg" — PATH
+    //        search fails — `Io error: program not found`.
+    //      - Meanwhile the REAL data is at C:\ProgramData\SourceBoxSentry
+    //        with node.db + ffmpeg/ all present and the binary just
+    //        ignores it.
+    //
+    //    Requiring `node.db` inside `./data` anchors the legacy check to
+    //    actual CloudNode state, not a coincidentally-named directory.
+    //    Cargo-build dev workflows are unaffected: their `./data` always
+    //    has node.db once setup has run there. Empty or unrelated
+    //    `./data` folders fall through to the platform default.
     let legacy = PathBuf::from("./data");
-    if legacy.exists() {
+    if legacy.join("node.db").exists() {
         return legacy;
     }