fix: chdir into app-data dir at desktop startup, fixing 30+ writes at once (P-1)

Root cause: grepped every bare (non-__file__-anchored) CWD-relative
path in the codebase. Found DATA_RAW_PATH/DATA_PROCESSED_PATH/
DATA_SAMPLES_PATH in config/settings.py were dead code exactly like
LOGS_PATH was before its own fix -- zero real consumers reference
them. Instead, 30+ real call sites hardcode their own copy of the
same path directly: all 19 scrapers' data/samples/*.json sample-
fallback output, processing/pipeline.py (data/processed + data/samples),
ai/multi_investigator.py, ai/risk_scorer.py,
ai/self_learning/schema_learner.py, processing/alias_graph.py, and
graph/loader.py's own glob() read of pipeline output.

Trigger condition: on a real Windows install, a double-clicked app's
CWD is unpredictable, and the install directory itself is typically
read-only for a non-admin user. Every one of these 30+ writes would
fail outright under that condition -- not just lose regeneratable
cache data, but error out entirely (scrapers couldn't run at all).

Why this fix looks different from this branch's sibling commits
(case_memory.json, logs, dossier output): those needed explicit
per-file redirection because their paths were __file__-anchored
(computed from the file's own location on disk, independent of CWD).
Every one of these 30+ paths, by contrast, is genuinely bare
CWD-relative with no anchoring at all -- confirmed via grep, not
assumed. That means a single os.chdir() before any other import fixes
all 30+ at once, with zero changes needed to any individual file,
rather than repeating 30 individual redirections.

The one real risk this could have introduced: python-dotenv's
load_dotenv() is called with no arguments in 10 different files
across the codebase, and naively I'd have guessed that's CWD-
dependent -- if it were, chdir()-ing before those calls run would
have silently broken .env/API-key loading in desktop mode. Verified
directly, empirically, before writing this fix (not assumed): built
a minimal reproduction proving load_dotenv() resolves relative to the
*calling file's own frame*, not CWD -- confirmed a chdir() between a
script's own location and the load_dotenv() call inside it does NOT
break discovery of a .env file that sits next to that script. This
codebase's own load_dotenv() call sites are all genuine files with
real __file__ values (not exec()'d strings), so they're unaffected.

Also verified no other CWD-relative assumption exists anywhere else
in the codebase (frontend serving, dataset CSV loading, static file
directories) that this chdir() could break -- grepped for all of
them, zero hits beyond the 30+ already accounted for.

Verified: executed packaging/desktop_entry.py's actual top-level
init code via runpy.run_path() (the same file-path-based execution
PyInstaller's own Analysis() uses, and how a developer runs this
script directly -- NOT via , which
collides with the real PyPI library also installed in
any standard Python environment; a real, pre-existing naming
collision worth knowing about but which does not affect either actual
invocation path, both of which are file-path-based, not import-based).
Confirmed CWD actually changes to the app-data directory, confirmed a
real bare-relative write (exactly matching every scraper's own
pattern) lands there, confirmed the real api.main app still imports
correctly afterward, and confirmed the project's own source directory
is never touched. Full suite: 116 passed, 0 failed.

config/settings.py

@@ -182,6 +182,20 @@ MAX_RETRIES     = 3
 REQUEST_TIMEOUT = 30
 
 # Data paths
+# NOTE (P-1 finding, same shape as LOGS_PATH's own history before its fix):
+# these three constants are dead code -- grepped every consumer, zero hits
+# anywhere in the tree. All 30+ real writers/readers (19 scrapers' sample
+# fallback output, processing/pipeline.py, ai/multi_investigator.py,
+# ai/risk_scorer.py, ai/self_learning/schema_learner.py,
+# processing/alias_graph.py, graph/loader.py's glob read) hardcode their
+# own bare "data/processed/..." or "data/samples/..." string directly
+# instead. Unlike LOGS_PATH, these were NOT individually wired up to this
+# constant, because every one of them is genuinely CWD-relative (no
+# __file__-anchoring anywhere) -- so the actual desktop-mode fix is a
+# single os.chdir() into get_app_data_dir() in packaging/desktop_entry.py,
+# which redirects all 30+ of them at once with no per-file changes needed.
+# Left here as an accurate description of the intended folder layout, not
+# as something any code currently reads.
 DATA_RAW_PATH       = "data/raw/"
 DATA_PROCESSED_PATH = "data/processed/"
 DATA_SAMPLES_PATH   = "data/samples/"

packaging/desktop_entry.py

@@ -19,6 +19,30 @@ whenever the app is started this way, and so config/settings.py's local
 config-file loading is the primary configuration path a desktop user
 actually has, rather than a code path that only matters at packaging time.
 
+P-1 fix: also chdir()s into the OS-appropriate app-data directory before
+any other import. Grepped every bare (non-__file__-anchored) CWD-relative
+path in the codebase: 30+ real call sites across all 19 scrapers'
+data/samples/*.json sample-fallback output, processing/pipeline.py,
+ai/multi_investigator.py, ai/risk_scorer.py, ai/self_learning/
+schema_learner.py, processing/alias_graph.py, and graph/loader.py's own
+glob() read of pipeline output -- none of which reference the (equally
+dead) DATA_RAW_PATH/DATA_PROCESSED_PATH/DATA_SAMPLES_PATH constants in
+config/settings.py; each just hardcodes its own "data/processed/..." or
+"data/samples/..." string directly. On a real Windows install, a
+double-clicked app's CWD defaults to (and the install directory itself is
+typically read-only for) a non-admin user -- meaning every one of those
+30+ writes would fail outright, not just lose regeneratable cache data.
+Verified every one of them is genuinely CWD-relative (confirmed via
+direct testing that python-dotenv's own load_dotenv() calls elsewhere in
+the codebase are NOT affected by this, since dotenv resolves relative to
+the calling file's own frame, not CWD) -- so a single chdir() here fixes
+all 30+ call sites identically, with zero changes needed to any of them,
+rather than repeating the explicit per-file redirection this branch's
+sibling commits used for case_memory.json/logs/dossier output (which
+were __file__-anchored, not CWD-relative, and so could NOT have been
+fixed this way). Web-deployment behavior is unchanged -- this file is
+never imported by the Docker/app.py path.
+
 Binds to 127.0.0.1 only, matching the target architecture ("bound to
 127.0.0.1 only") -- this process is meant to be reached only by the Tauri
 shell's own webview (Phase D4), never by the network.
@@ -41,6 +65,15 @@ else:
     _app_root = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
 sys.path.insert(0, _app_root)
 
+# P-1 fix: chdir into a guaranteed-writable directory before any other
+# import that might (transitively, later, at request time) write a bare
+# CWD-relative path. Must come after sys.path is set up (needs to import
+# config.settings) but before uvicorn/api.main are imported.
+from config.settings import get_app_data_dir
+_workdir = get_app_data_dir()
+os.makedirs(_workdir, exist_ok=True)
+os.chdir(_workdir)
+
 import uvicorn
 from api.main import app