multistreaming: scenes/composition, installer build support, service updates

- multistreaming (new): RTMP ingest + multi-platform fan-out with pluggable providers (Twitch/YouTube/Kick/custom), zero-knowledge key vaults, Authelia OIDC auth, shared rooms with editor/streamer roles, single-use invites, per-account streaming grants, and scenes & composition (grid/PiP layouts, text/image overlays, per-output audio routing).
- installer: support Dockerfile build in metadata (not just image) and RSA key generation for the Authelia OIDC JWKS.
- authelia: add OIDC provider with portainer + multistreaming clients (public + PKCE).
- services: remove allprox; add nginx-proxy-manager and portainer; update lldap; regenerate catalog.

services/README.md

@@ -2,7 +2,7 @@
 
 One folder per service. Each folder must contain a `metadata.json` describing the service
 (including the Docker Compose definition used to deploy it). The folder may also contain any extra
-files the service needs — a `Caddyfile`, a `Dockerfile`, static assets — which the installer copies
+files the service needs — a config file, a `Dockerfile`, static assets — which the installer copies
 into the deploy directory.
 
 ## Folder conventions
@@ -20,25 +20,27 @@ into the deploy directory.
 
 ## Extra files
 
-A service folder can contain files beyond `metadata.json` — for example the `allprox` service ships
-a `Caddyfile` and a `portal/index.html`. On install/update the installer copies the whole folder
-(except `metadata.json`) into `~/.homelab/services/<id>/`, preserving subdirectories.
+A service folder can contain files beyond `metadata.json` — for example the `authelia` service ships
+a `configuration.yml` and a `users_database.yml`, while the `multistreaming` service ships a `Dockerfile`,
+`package.json`, `src/`, and `web/` for its `build`. On install/update the installer copies the whole
+folder (except `metadata.json`) into `~/.homelab/services/<id>/`, preserving subdirectories.
 
 Reference those files from `compose.volumes` with **relative** paths:
 
 ```json
 "volumes": [
-  "./Caddyfile:/etc/caddy/Caddyfile:ro",
-  "./portal:/srv/portal:ro"
+  "./configuration.yml:/config/configuration.yml:ro",
+  "./users_database.yml:/config/users_database.yml:ro"
 ]
 ```
 
 Because the generated `docker-compose.yml` lives in the same directory, `docker compose` resolves
-the `./...` paths against it.
+the `./...` paths against it — and, for `build` services, the `.` build context is that same
+directory, so the Dockerfile and source files are found automatically.
 
 ## Shared networks
 
-Services that need to talk to each other (e.g. `allprox` → `authelia` → `lldap`) join an external
+Services that need to talk to each other (e.g. `nginx-proxy-manager` → `authelia` → `lldap`) join an external
 Docker network. Declare it at the top level of `metadata.json` and attach the service to it:
 
 ```json
@@ -77,8 +79,9 @@ A machine-readable JSON Schema is available at [`docs/metadata-schema.json`](../
 
 ### `compose` (the service definition)
 
-This object is the value you would normally put under a service key in `docker-compose.yml`. For
-example:
+This object is the value you would normally put under a service key in `docker-compose.yml`. It must
+set **either** `image` (pull a prebuilt image) **or** `build` (build from a Dockerfile shipped in the
+service folder). Pull example:
 
 ```json
 {
@@ -91,17 +94,24 @@ example:
 }
 ```
 
-The installer turns it into:
+Build example (the Dockerfile, source files, and `.dockerignore` live in the service folder and are
+copied into the deploy directory, so the build context is `.`):
 
-```yaml
-services:
-  myapp:
-    image: ghcr.io/example/myapp:1.0.0
-    # ...
+```json
+{
+  "build": { "context": ".", "dockerfile": "Dockerfile" },
+  "container_name": "myapp",
+  "restart": "unless-stopped",
+  "ports": ["8080:8080"],
+  "volumes": ["myapp_data:/data"],
+  "environment": ["TZ=${TZ}"]
+}
 ```
 
-Pin images to a tag so updates are predictable; the installer compares `version` to decide whether
-an update is available.
+The installer turns either into a `docker-compose.yml` service. On install it runs
+`docker compose build` (for `build` services) or pulls the image on update; then `docker compose up -d`
+brings the container up. For image-based services, pin the tag so updates are predictable — the
+installer compares `version` to decide whether an update is available.
 
 ### `env` (interactive variables)
 
@@ -129,3 +139,23 @@ Each entry describes a variable the installer should collect (and write to `.env
 
 Docker Compose automatically reads the `.env` written next to the generated compose file, so
 `${NAME}` references resolve at `docker compose up` time.
+
+### `rsaKeys` (generated private keys)
+
+For secrets that cannot be injected via environment variables — most notably Authelia's OIDC
+signing key (`identity_providers.oidc.jwks.key`, which rejects `$file:`/`$env:` secret references) —
+declare an RSA private key the installer generates into a file on first install:
+
+```json
+"rsaKeys": [
+  { "name": "OIDC_JWKS_KEY", "path": "oidc-jwks.pem", "bits": 2048 }
+]
+```
+
+- `name` (required) — human label.
+- `path` (required) — file written into the service's deploy directory, referenced by a relative
+  `./path:...` bind mount in `compose.volumes`.
+- `bits` — RSA modulus size (default 2048).
+
+The key is only created if the file is absent, so updating a service never rotates the key and
+invalidates existing sessions.