Desktop: user CSS can reveal normally hidden Host bootstrap scripts in head (repro and tested containment)

[ysr666]

Independent Host-side reproduction (not a diagnosis of a user's screenshot)

In an isolated Windows Node 24.21 / official DSH 0.2.2-rc.1 Electron Desktop profile, third-party/user CSS that resets native element display can expose the normally hidden <head> and render DSH's own inline bootstrap JS/CSS visibly at the top of the Desktop screen, despite document.contentType === "text/html". This can visually match a reported "raw JavaScript/CSS wall" without a plugin response-MIME or parser failure.

No Vision Router required: an independent clean-profile A/B/A with only the Host and pinned external dsh-custom-style CSS plugin reproduced the raw-source display when a deliberately synthetic * { all: unset !important } rule was loaded; removing that one CSS rule restored the hidden head in the same Electron process. Initial cold-launch reproduction was also confirmed.

Tested containment candidate

The existing Desktop document owns the Host bootstrap <head> and its inline __DSH_BOOT_READY__. In isolated Host source only, making the generated <head style="display: none !important"> explicitly nonrendering prevented the boot source becoming visible while the hostile CSS remained loaded. The Host boot promise and the normal Vision image→tool→chat flow continued to work. A real Chromium matrix covering ordinary, universal reset/display and explicit head styles passed 8/8, and a focused Vitest test was red on original upstream code / green on the candidate.

Reviewable fork-only candidate: ysr666@06b8896 . Detailed DVR investigation: ysr666/dsh-vision-router#792 .

Boundaries / ask

• This proves a general Desktop HTML/CSS containment issue; it does not establish that the original community reporter actually installed this CSS or identify their true cause.
• Global CSS resets may also damage other UI elements; protecting the head is not a universal theme/plugin fix.
• No user profile, session data or release artifacts were changed in these probes.
• Upstream Issues are disabled and a fork-to-upstream PR attempt under this contributor account returned CreatePullRequest permission denied. Could the maintainers review the minimal Host-owned containment and advise the preferred protected head/document behavior?