feat(security): add a user-writable plugin ingest inbox for cross-account data

The LocalService runner can't traverse the interactive user's profile the way
the old SYSTEM runner could — so a plugin can no longer read a file an app
running as *you* produced (the acute case: the Playnite exporter's library
JSON under %APPDATA%). Confirmed on-glass: as LocalService the glob finds
nothing and the profile is un-traversable.

Add the inverse of plugin-state: <config_dir>\ingest, granted BUILTIN\Users
Modify by plugins enable (disable reverts to inherited Users:RX). An
interactive-user app drops ingest\<plugin>\… and the de-privileged runner
reads it there — the one Users-writable carve-out in the otherwise
Users-read-only tree. SDK exports pluginIngestDir(name) to resolve it; on
Linux the systemd --user runner owns the config dir so same-user producers
write there with no grant.

Accepted tradeoff: the inbox is writable by any local user (trusted-single-
user model; it feeds only a LocalService runner). Consumers must treat ingest
data as lower trust than their own state.

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

sdk/README.md

@@ -176,6 +176,22 @@ plugins enable` grants the runner write on exactly `plugin-state` — the config
 *code* stay read-only. On Linux the runner owns the whole config dir, so the same path is writable
 with no special step.
 
+### Receiving data from an interactive-user app — `pluginIngestDir`
+
+If a plugin needs data produced by a **different account** — e.g. a desktop app running as the
+logged-in user, like the Playnite exporter — it can't read it from that user's profile: the
+de-privileged Windows runner can't traverse `C:\Users\<you>\…`. `pluginIngestDir("<your-name>")`
+resolves an inbox (`<config_dir>/ingest/<name>`) that `plugins enable` makes **user-writable**, so
+your app drops a file there and the runner reads it:
+
+```ts
+import { pluginIngestDir } from "@punktfunk/host";
+const inbox = pluginIngestDir("playnite"); // <config_dir>/ingest/playnite  (your app writes here)
+```
+
+Treat what you read from it as lower trust than your own state — the inbox is writable by any local
+user.
+
 ### A plugin UI in the console — `servePluginUi`
 
 A plugin can surface a web UI **inside the punktfunk console** — no second password or port for the

sdk/src/config.ts

@@ -72,6 +72,27 @@ export const pluginStateDir = (name?: string): string => {
 	return name ? path.join(root, name) : root;
 };
 
+/**
+ * The ingest inbox a plugin reads data DROPPED BY ANOTHER ACCOUNT from:
+ * `<config_dir>/ingest[/<name>]`.
+ *
+ * The mirror of {@link pluginStateDir}, and the answer to a problem the de-privileging creates on
+ * Windows: the LocalService runner can no longer traverse the interactive user's profile, so a
+ * plugin can't read a file an app running as *you* produced (e.g. the Playnite exporter's library
+ * JSON under your `%APPDATA%`). `punktfunk-host plugins enable` grants `BUILTIN\Users` **write** on
+ * exactly `ingest` — so your app drops `ingest/<plugin>/…` and the runner reads it there. On Linux
+ * the runner is a `systemd --user` unit owning the config dir, so a same-user producer writes here
+ * with no special step.
+ *
+ * The dir is NOT created here (a producer running as the interactive user creates its own
+ * `ingest/<name>` subdir under the host-granted `ingest`). Treat anything read from it as
+ * lower-trust than your own state: the inbox is writable by any local user.
+ */
+export const pluginIngestDir = (name?: string): string => {
+	const root = path.join(configDir(), "ingest");
+	return name ? path.join(root, name) : root;
+};
+
 const readIfExists = (p: string): string | undefined => {
 	try {
 		return fs.readFileSync(p, "utf8");

sdk/src/index.ts

@@ -32,6 +32,8 @@ export { HttpStatusError } from "./core.js";
 export type { ConnectOptions } from "./config.js";
 // A plugin persists its state here — the one dir the de-privileged Windows runner may write.
 export { pluginStateDir } from "./config.js";
+// A plugin reads cross-account data (dropped by an interactive-user app) from here.
+export { pluginIngestDir } from "./config.js";
 export {
 	type PluginUiHandle,
 	type PluginUiOptions,

sdk/test/config.test.ts

@@ -2,7 +2,7 @@
 // plugin persists into — the one dir the de-privileged Windows runner may write.
 import { afterEach, beforeEach, describe, expect, test } from "bun:test";
 import * as path from "node:path";
-import { pluginStateDir } from "../src/config.js";
+import { pluginIngestDir, pluginStateDir } from "../src/config.js";
 
 describe("pluginStateDir", () => {
 	let saved: string | undefined;
@@ -27,3 +27,24 @@ describe("pluginStateDir", () => {
 		expect(pluginStateDir("x").startsWith(pluginStateDir())).toBe(true);
 	});
 });
+
+describe("pluginIngestDir", () => {
+	let saved: string | undefined;
+	beforeEach(() => {
+		saved = process.env.PUNKTFUNK_CONFIG_DIR;
+	});
+	afterEach(() => {
+		if (saved === undefined) delete process.env.PUNKTFUNK_CONFIG_DIR;
+		else process.env.PUNKTFUNK_CONFIG_DIR = saved;
+	});
+
+	test("resolves <config_dir>/ingest[/name], distinct from plugin-state", () => {
+		process.env.PUNKTFUNK_CONFIG_DIR = path.join("/tmp", "pf-cfg3");
+		expect(pluginIngestDir()).toBe(path.join("/tmp", "pf-cfg3", "ingest"));
+		expect(pluginIngestDir("playnite")).toBe(
+			path.join("/tmp", "pf-cfg3", "ingest", "playnite"),
+		);
+		// the inbox (Users-write) is a different tree from state (LocalService-write)
+		expect(pluginIngestDir("playnite")).not.toBe(pluginStateDir("playnite"));
+	});
+});