Name the datasets as the sibling apps do

Back to the sibling apps' pattern: an overridable MAIN_DATASET /
SETTINGS_DATASET, explicit on the main stack (festipod-test /
settings-festipod-test), computed from DATASET_PREFIX and the service name when
left empty (previews). One convention across the apps is simpler for the
developers who move between them than a local variant.

Reverts the previous commit's compose change; the deployment leaf keeps one
line on why Coolify shows those two variables holding expression text.

.project/concepts/tech-stack/knowledge_deployment.md

@@ -8,7 +8,7 @@ last_checked: 2026-10-19
 
 ## The Coolify test stack
 
-`docker-compose.coolify.yml` is what Coolify (build pack *Docker Compose*) builds and runs from the git repository, on the test server only for now: `frontend` (the root `Dockerfile`, below), `backend` (`backend/Dockerfile`, Moleculer + `@activitypods/app`) and a per-stack Redis. Fuseki is the one shared with the other ActivityPods apps of the Coolify instance (`shared-infra`): only the backend joins the external `coolify` network to reach it, with a pair of datasets of its own named from `DATASET_PREFIX` and the backend's service name (a second non-preview stack on the same Fuseki needs its own prefix). The variables Coolify must carry are listed at the top of the compose file; `SERVICE_FQDN_*` / `SERVICE_NAME_*` are generated by Coolify, the latter only at deploy time (stored empty). **A compose value starting with `${VAR:-default}` makes Coolify create `VAR` with the default text as its stored value** (when the variable does not exist yet; the preview scope gets its own copy at creation). A default that is itself an expression — the sibling apps' `${MAIN_DATASET:-${DATASET_PREFIX:-…}-${SERVICE_NAME_BACKEND}}` override — is therefore stored as expression text: it READS as unresolved in Coolify's UI (observed 2026-10-19), yet works, since Coolify writes it unescaped into the `.env` after the `SERVICE_NAME_*` lines and docker compose resolves `${…}` inside `.env` values (verified with compose; the Coolify side traced in its 4.4.6 source, not observed live). Festipod has no historical datasets to keep, so it computes the names directly and carries no such misleading variable.
+`docker-compose.coolify.yml` is what Coolify (build pack *Docker Compose*) builds and runs from the git repository, on the test server only for now: `frontend` (the root `Dockerfile`, below), `backend` (`backend/Dockerfile`, Moleculer + `@activitypods/app`) and a per-stack Redis. Fuseki is the one shared with the other ActivityPods apps of the Coolify instance (`shared-infra`): only the backend joins the external `coolify` network to reach it, with a pair of datasets of its own, named as on the sibling apps: explicit `MAIN_DATASET` / `SETTINGS_DATASET` for the main stack (`festipod-test` / `settings-festipod-test`), computed from `DATASET_PREFIX` and the backend's service name when left empty (a preview: `festipod-backend-pr-<n>`). Coolify stores the compose default of those two variables, itself an expression, as their value — it reads as unresolved text in its UI but resolves at deploy time; setting explicit names avoids the confusion. The variables Coolify must carry are listed at the top of the compose file; `SERVICE_FQDN_*` / `SERVICE_NAME_*` are generated by Coolify at deploy time.
 
 **One base URL per environment** (user decision 2026-10-19, so a pull-request preview lives on a single host, like the sibling apps): the app at `https://festipod.dev.reconnexion.coop/`, the backend on the same host under `/api` — its Domains field is `https://<host>/api,https://<host>/.well-known`. Coolify's **Strip Prefixes must be OFF** (it is on the sibling apps): the backend mounts its routes under `/api` itself, read from `SEMAPPS_HOME_URL=https://<host>/api/`, and the front end is pointed at `VITE_BACKEND_URL=https://<host>/api`. With the prefix stripped every backend request is refused (404).