Expose consistent semantic material controls for transient surfaces

### Feature Description

DMS currently exposes global controls for popup transparency and background blur, but visually related transient surfaces do not always follow the same material behaviour.

Tested on:

CachyOS
Niri 26.04
DMS v1.6.0
dms-shell 1.6.0-2
Quickshell 0.3.1

The configuration tested was:

popupTransparency = 0.70
blurEnabled = true
blurForegroundLayers = false
modalDarkenBackground = false
notificationForegroundLayers = true

With these settings, the launcher behaves as expected: it becomes clearly translucent, the background blur is visible, and the foreground content remains readable.

However, other related transient surfaces such as the Control Center, battery, clipboard, notifications, and some Network/Bluetooth/audio detail views remain much more opaque. The difference is large enough that the UI no longer feels like one coherent material system.

This does not appear to be caused by the global transparency setting failing. Some DMS components use the shared popup transparency value, while others apply their own opacity rules when blur is enabled.

For example, some surfaces use:

Theme.withAlpha(Theme.surfaceContainer, Theme.popupTransparency)

while others use patterns such as:

BlurService.enabled
? Theme.surfaceContainer
: Theme.withAlpha(Theme.surfaceContainer, Theme.popupTransparency)

or fixed opacity values such as:

Theme.withAlpha(
Theme.surfaceContainer,
BlurService.enabled ? 0.96 : Theme.popupTransparency
)

Notification components also include cases where an opaque Theme.surfaceContainer or fixed opacity values such as 0.95 are used while blur is active.

As a result, visually related transient UI can currently mix:

the configured popupTransparency

transparent nested or foreground layers

fixed opacity values such as 0.95 / 0.96

fully opaque surfaceContainer

The request is not to make every transient surface use exactly the same opacity. Different surface roles may legitimately need different strengths for readability and hierarchy.

The request is for a supported semantic material system that allows these related surfaces to be controlled coherently as part of one theme.

### Use Case

I am creating a custom DMS theme and wanted to use the existing transparency and blur features across transient UI.

The launcher showed that the effect can work very well, but other related surfaces remained much more opaque because they use different material behaviour internally.

This created a visible mismatch between parts of the same shell. I eventually reverted the whole setup back to fully opaque surfaces because a consistent appearance was preferable to having some transient surfaces translucent and others effectively opaque.

A supported semantic material system would allow theme authors to define a coherent relationship between different surface roles, for example:

base transient surface

nested or elevated surface

detail or selector surface

notification surface

These roles could still use different opacity values where appropriate, but they would be controlled as part of one material system instead of through unrelated component-specific values.

### Compositor(s)

All compositors

### If Other, please specify

_No response_

### Proposed Solution

Expose supported transient-surface material roles through the existing theme or settings system.

For example, DMS could provide semantic roles such as:

transientBaseOpacity
transientNestedOpacity
transientDetailOpacity
transientNotificationOpacity

The current DMS appearance could remain as the default, so existing users would not need to change anything.

Built-in components such as Network detail views, Bluetooth/audio selectors and notification cards could then consume semantic material roles instead of relying on fixed values such as 0.95 / 0.96 or switching directly to fully opaque surfaceContainer when blur is active.

Another possible approach would be a supported material/theme extension API that lets theme authors control these relationships without modifying DMS QML.

The important part is that transient surfaces should be able to share one coherent material language while still allowing legitimate differences in hierarchy and readability.

### Alternatives/Existing Solutions

I tested the existing supported controls before raising this request.

popupTransparency works, but does not override component-specific material behaviour.

Background blur works.

blurForegroundLayers = false correctly enables the more transparent foreground-layer path, but components that explicitly choose their own opaque or fixed-opacity surfaces remain unaffected.

notificationForegroundLayers = false was also tested, but notification cards can still remain opaque because their own QML applies a different material treatment while blur is active.

Custom theme colour roles can change colours such as surfaceContainer and surfaceContainerHigh, but do not provide control over these component-specific opacity choices.

Lowering global popup transparency further makes the surfaces that already follow it too transparent.

Disabling blur removes the desired effect rather than solving the inconsistency.

Modifying or forking DMS QML could solve it locally, but creates maintenance and update problems and avoids the supported theming system.

For now I have reverted to the previous cohesive opaque configuration:

popupTransparency = 1
blurEnabled = false
blurForegroundLayers = true
modalDarkenBackground = true
notificationForegroundLayers = true

Related issue #3212 asks for the existing popup transparency and blur controls to be exposed in the Settings UI. This request is different: it is about making the built-in transient surfaces participate in a coherent, themeable material system once those controls are enabled.

Start by tracing popupTransparency, blurEnabled, and foreground-layer handling across the launcher, Control Center, battery, clipboard, notifications, and Network/Bluetooth/audio detail surfaces. Compare the cited Theme.withAlpha and Theme.surfaceContainer paths, then determine which material roles need supported theme or settings exposure. Done means related transient surfaces retain current defaults while responding coherently to the semantic controls.

Written by the indexing model from the issue text.