Scoped labels (scope::value) that survive blueprint sync, plus label inheritance from sites

[strausmann]

Summary

Extend the existing resource/site labels with:

1. Scoped labels in the form scope::value (e.g. platform::php, platform_version::8.4.2, location::dc-a), rendered like GitLab scoped labels (two-part badge), with at most one value per scope on the same object.
2. Per-assignment origin (blueprint / manual), so a blueprint sync only replaces the label assignments it owns and keeps labels added in the UI/API.
3. Inheritance from sites: a resource's effective labels are its own labels plus the labels of every site its targets run on.

Motivation

Labels are a great way to group resources, but today they can't be used as a reliable grouping key when resources come from Docker-label blueprints:

• syncResourceLabels() (server/lib/blueprints/labels.ts) deletes all label assignments of a resource and re-inserts only the blueprint's list. Any label added in the UI disappears on the next sync (same class of problem as Blueprint overwriting non configured settings #2197).
• Information that belongs to the site (datacenter, provider, environment) has to be repeated on every resource.
• Flat labels can't express "key with a value" cleanly, so filtering by e.g. "every resource on platform X" or "every resource on a version range" isn't possible.

I ran into this during PHP2Shell (CVE-2026-109618 / CVE-2026-109619): I wanted to find and restrict every PHP application behind Pangolin at once, and labels were the obvious grouping key — but labels I added in the UI were gone after the next sync. This is the building block for #3979 (label-scoped access policies), but it is useful on its own for filtering and overview, as requested in #1414.

Proposed Solution

• Scoped labels: a label name containing :: is a scoped label. UI renders scope and value as a two-part badge. Setting platform_version::8.4.27 on a resource replaces an existing platform_version::* on the same resource (GitLab semantics).
• Origin per assignment: add an origin column to resourceLabels / siteLabels (blueprint | manual). Blueprint sync deletes/re-inserts only rows with origin = blueprint. Removing a label in the UI never writes back to the blueprint. Existing rows can be migrated as blueprint when the resource is blueprint-managed, otherwise manual.
• Inheritance: effective labels = own labels ∪ labels of all sites of the resource's targets. For evaluation and display they are namespaced by origin: resource:<scope>::<value> and site:<scope>::<value>, so an inherited value never conflicts with an own value. Storage stays as today; people writing blueprints still write plain scope::value.
• UI: show own and inherited labels separately; inherited labels show the site they come from and can't be removed on the resource.
• API: the existing labels list filters accept scoped labels and the namespaced form.

Alternatives Considered

• Keep flat labels and use naming conventions (platform-php) — works for display, but can't express version ranges or "one value per scope", and still loses UI-added labels on sync.
• Declare every label in the blueprint — doesn't help for site-level facts and makes central grouping depend on every stack owner.

Additional Context

• Related: [FEAT] Label / Tags for Resources/Sites/Domains #1414 (labels/tags), Blueprint overwriting non configured settings #2197 (blueprint overwriting settings it doesn't define), Visual indicator and protection of resources created by docker labels #1860 (protecting blueprint-managed resources — compatible: the blueprint stays authoritative for the assignments it owns).
• Builds the base for Label-scoped access policies that take precedence over resource rules (incident kill switch) #3979 and Idea — automatically detect platform labels for containers (e.g. language runtime and version) #3980.
• I'd be happy to implement the per-assignment origin as a first, small PR if this direction is acceptable, and I'm glad to coordinate here or in a Discord chat.
• AI disclosure: this request was drafted with the help of an AI assistant (Claude Code), based on reading the current dev source; I reviewed and edited it.