feat(app): allow per-map layer labels for shared layers

[antontranelis]

Problem

A layer can be attached to several maps, and that is how content is shared between them. Its name and menuText are global though, so a layer shown on both a German and an English map has to settle on one language.

Approach

The layers_maps junction row already carries the meaning "this layer, on this map", so the per-map label belongs there rather than on the layer or the map.

Two optional fields on that junction, name and menuText, override the layer's own labels for that map only. layersApi requests them alongside the existing fields and overlays them after fetching.

Blank and missing values fall back to the layer's labels, so every existing map keeps its current labels untouched — no data migration, no behaviour change for maps that never set an override.

Directus fields

The matching fields have been added to layers_maps on the production instance (both nullable strings, interface: input, with a note explaining the fallback). They are readable by the public role, which the frontend relies on.

Verified against the live API: on Docutopia the shared Bäume / Gärten layers resolve to Trees / Gardens, while the German map returns no overrides and keeps the layer labels.

Tests

app had no test setup, so this adds a minimal one: vitest as a dev dependency and a test:unit script, with the test block in the existing app/vite.config.ts.

The label overlay lives in its own module app/src/api/layerLabels.ts so it can be tested without pulling in the Directus client, which reads env vars at import time. Six cases are covered: override applied, blank override falls back, each label overridden independently, expanded maps_id object, junction rows of other maps and dangling rows ignored, and the un-expanded junction left untouched.

npx tsc --noEmit, eslint --max-warnings 0 and vitest run all pass in app.

🤖 Generated with Claude Code