fix: read/write the library via the host ingest inbox (de-privileged runner)

The host plugin runner is de-privileged now (LocalService) and can't read the
interactive user's %APPDATA%\Playnite\ExtensionsData — so it never saw the
export. Bridge it through the host's user-writable ingest inbox:

- exporter (C#): also drop punktfunk-library.json into
  %ProgramData%\punktfunk\ingest\playnite (best-effort, only when a punktfunk
  host is present), alongside its ExtensionsData home.
- plugin (TS): locateExport() reads <config_dir>/ingest/playnite first, then
  falls back to the ExtensionsData scan (same-user/SYSTEM runner, Linux). The
  watcher also watches the inbox so a drop reconciles within seconds.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

src/playnite.ts

@@ -5,9 +5,12 @@
 // from the exporter's id.
 //
 // The plugin runs on the same box as Playnite (it's the streaming host), so these are plain local
-// reads. The one wrinkle is *which user's* `%APPDATA%`: if the runner runs as the interactive user we
-// find it directly; if it runs as SYSTEM/another user we fall back to scanning `C:\Users\*`. An
-// explicit `playniteDir` in the config always wins.
+// reads. The wrinkle is *which account* can see the file. The managed runner is de-privileged
+// (`NT AUTHORITY\LocalService`) and cannot read the interactive user's `%APPDATA%`, so the reliable
+// source is the **ingest inbox** (`<config_dir>/ingest/playnite/punktfunk-library.json`) the
+// exporter drops the file into — checked FIRST. The `%APPDATA%`/`C:\Users\*` ExtensionsData scan
+// still works for a same-user/SYSTEM runner or on Linux, and an explicit `playniteDir` override
+// joins the candidate list.
 
 import * as fs from "node:fs";
 import * as path from "node:path";
@@ -18,6 +21,7 @@ import {
 	type LibraryExport,
 	SCHEMA,
 } from "./export-schema.js";
+import { ingestDir } from "./paths.js";
 
 const exists = (p: string): boolean => {
 	try {
@@ -96,15 +100,38 @@ export const locateExport = (config: Config): Location => {
 		? [override, ...candidatePlayniteDirs()]
 		: candidatePlayniteDirs();
 
-	// First, a dir that actually holds an export file.
+	// The ingest inbox first: the exporter drops the library here (a flat file, not an
+	// `ExtensionsData/<guid>` tree) so the de-privileged LocalService runner can read it — it can't
+	// reach the interactive user's `%APPDATA%`. This is the reliable path on a managed Windows host.
+	const inbox = ingestDir();
+	const inboxFile = path.join(inbox, EXPORT_FILE);
+	try {
+		const st = fs.statSync(inboxFile);
+		return {
+			dir: inbox,
+			candidates: [inbox, ...candidates],
+			file: inboxFile,
+			mtime: st.mtimeMs,
+		};
+	} catch {
+		// no ingest drop yet — fall back to scanning Playnite's own data dirs
+	}
+
+	// Then, a Playnite data dir that actually holds an export file (same-user/SYSTEM runner, Linux).
 	for (const dir of candidates) {
 		const hit = findExportUnder(dir);
-		if (hit) return { dir, candidates, file: hit.file, mtime: hit.mtime };
+		if (hit)
+			return {
+				dir,
+				candidates: [inbox, ...candidates],
+				file: hit.file,
+				mtime: hit.mtime,
+			};
 	}
 	// Else, the first dir that at least exists (so the UI can say "Playnite found, exporter not
 	// installed yet" vs "Playnite not found").
 	const dir = candidates.find(exists) ?? null;
-	return { dir, candidates, file: null, mtime: null };
+	return { dir, candidates: [inbox, ...candidates], file: null, mtime: null };
 };
 
 export class ExportError extends Error {}