feat(store): console plugin store, index repo, and the fixes on-glass found

Console: a Plugins section (Browse / Installed / Sources) on a static nav
entry, with install friction proportional to trust — a plain confirm for a
verified entry, a warning naming the curator for an external one, and a
danger dialog that makes you retype the spec for a raw package. Tier badges
are permanent and follow the plugin onto its own UI page.

Index: unom/punktfunk-plugin-index published and served from Gitea's raw
endpoint (real HTTPS, byte-exact, no vhost to stand up) — merge to main is
publish, which resolves the design's open hosting question.

Four things only running it could find:
- runner discovery matched @punktfunk/plugin-* only, so a third-party
  scoped plugin (which D8 requires) would install and never run
- ...and that convention also matches @punktfunk/plugin-kit, a plugin's
  own framework: it listed as installed and would have been imported as a
  unit. Both now key off the plugins dir's top-level dependencies, with an
  emptied dependency list meaning 'nothing installed' rather than falling
  back to the naming convention
- the store must not pass new flags to the runner: the scripting package
  ships separately and an older one reads an unknown flag's value as a
  package name. The host writes the bunfig scope mapping itself
- ureq reports only >= 400 as Err, so a conditional request's 304 arrives
  as Ok with an empty body — handled as an error it made every refresh
  after the first verify a signature over zero bytes and sit stale

Also: the console's first Tabs use exposed an @unom/ui theme gap that
rendered inactive tabs invisible (caught in a browser pass, not by types).

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

sdk/src/runner.ts

@@ -302,8 +302,27 @@ export const discoverUnits = (
 		// no scripts dir — fine
 	}
 	const modules = path.join(pluginsDir, "node_modules");
+	// The packages the operator actually installed — `bun add` records them as the plugins dir's
+	// own `dependencies`. This is what separates a plugin from a plugin's LIBRARY:
+	// `@punktfunk/plugin-kit` matches the `plugin-*` naming convention exactly but arrives as a
+	// transitive dependency of every kit-built plugin, and running it as a unit is nonsense.
+	// `undefined` only when there is no readable `package.json` at all — a hand-assembled tree then
+	// falls back to the naming convention rather than discovering nothing. A package.json with no
+	// `dependencies` key yields an EMPTY set, not `undefined`: `bun remove` drops the key when the
+	// last plugin goes, and orphaned transitive packages can outlive it, so falling back there
+	// would start running a plugin's library the moment you uninstall the last real plugin.
+	let topLevel: Set<string> | undefined;
+	try {
+		const root = JSON.parse(
+			fs.readFileSync(path.join(pluginsDir, "package.json"), "utf8"),
+		) as { dependencies?: Record<string, string> };
+		topLevel = new Set(Object.keys(root.dependencies ?? {}));
+	} catch {
+		// no package.json — fall back to the convention
+	}
 	// Read a plugin package's manifest (`module`/`main` entry) and add it as a unit.
 	const addPlugin = (dir: string, name: string): void => {
+		if (topLevel && !topLevel.has(name)) return; // a dependency, not an installed plugin
 		try {
 			const manifest = JSON.parse(
 				fs.readFileSync(path.join(dir, "package.json"), "utf8"),