Import the MetaMesh app family from Worph/AppStore

23 apps (MetaCore, the library/network/client tiers and 13 MetaFeeder*)
move out of the general-purpose Worph/AppStore into their own store so the
MetaMesh family releases on its own cadence.

- asset URLs repointed to cdn.jsdelivr.net/gh/Worph/MetaAppStore@main
- store scaffolding added (category/recommend/featured lists, licence,
  contributing, gitattributes)
- psd-source/meta-icons-v2 icon generator follows the apps

MetaMCP stays in Worph/AppStore: it is third-party metatool-ai software,
not part of MetaMesh.

Apps/MetaFeederProwlarr/rationale.md

@@ -0,0 +1,47 @@
+# MetaFeeder · Prowlarr — Rationale
+
+## What deviation / exception is being requested
+
+`metafeederprowlarr-feeder` runs `user: 0:0`.
+
+## Why it is necessary
+
+The feeder publishes its resolved records to the shared MetaCore over HTTP and writes its
+own service registration and plugin artwork through MetaCore's WebDAV endpoint. Those
+writes land in directories created and owned by MetaCore's root-running container; a
+uid-1000 process is refused. The feeder image also runs a small supervised process group
+(fetcher + enrichment plugin clients) that expects to be able to signal its children.
+
+## Security mitigations in place
+
+- Public ingress terminates at the AppShield sidecar (`ghcr.io/yundera/appshield:2.0.9`),
+  which gates every path behind the PCS's Authelia SSO over OIDC. The feeder carries no
+  Caddy labels and publishes no host port, so it is reachable only from the `pcs` Docker
+  network.
+- The container mounts **no user directories** — not `/DATA/Documents`, `/DATA/Downloads`,
+  `/DATA/Media` or `/DATA/Gallery`. Its only bind is its own state under
+  `/DATA/AppData/metafeederprowlarr/`, declared in `x-compose-app.folders` and owned `$PUID:$PGID`.
+- `cpu_shares` set on every service; image tags pinned; no `:latest`.
+- The enrichment sidecars (`-filename-parser`, `-tmdb`) run **unprivileged** — no `user:`
+  field, so Yundera starts them as `$PUID:$PGID`. `-filename-parser` is on the app-private
+  `metafeederprowlarr` bridge only; `-tmdb` also joins `pcs` because MetaCore calls back into
+  it, and it carries an app-prefixed `container_name` so it cannot collide with another
+  app's service in the shared DNS namespace. Neither carries Caddy labels or publishes a
+  host port.
+
+## Alternatives considered and rejected
+
+- **Run as `$PUID:$PGID`.** Writes into MetaCore's root-owned `/meta-core` tree and through
+  its WebDAV endpoint fail, and the feeder starts but silently publishes nothing.
+- **Have MetaCore relax the ownership of its shared directory.** That would loosen
+  permissions for every MetaMesh app at once, which is strictly worse than one root
+  container with no user-data mounts.
+- **Drop privileges after startup inside the image.** Upstream change; tracked, not
+  available in the shipped image.
+
+## Data protection
+
+The feeder holds no user media. Its entire state — configuration, cursor position, and
+(where applicable) the TMDB cache — lives under `/DATA/AppData/metafeederprowlarr/`, which is the unit
+Maison archives on uninstall and restores from backup, so an uninstall/reinstall with "keep
+user data" resumes where it left off rather than re-indexing from scratch.