fix(desktop/windows): cut Memories-page GPU usage by removing backdrop-filter behind the brain graph

[kodjima33]

What

On the Windows desktop Memories page, the BrainGraph (React Three Fiber WebGL canvas) was wrapped in a .surface-card container, which applies .glass → backdrop-filter: blur(...). This PR replaces that glass wrapper with a flat solid-tint + hairline border, keeping the card look but removing the blur behind the canvas.

-<div className="surface-card relative h-80 overflow-hidden p-0">
+<div className="relative h-80 overflow-hidden rounded-2xl border border-white/[0.08] bg-black/40 p-0">

Why

From the issue (#8438):

Users are experiencing continuous, high GPU usage (50-60%+) when viewing the Memories page on the Windows desktop app. The GPU usage spikes exclusively when the 3D knowledge graph is visible on screen, and drops immediately to 3-5% when the graph is scrolled out of the viewport.

When a hardware-accelerated WebGL canvas is layered directly over or inside an element with backdrop-filter, the Windows Desktop Window Manager (DWM) and Chromium compositor are forced to continually re-blend the WebGL texture with the blurred background... any sub-pixel UI updates, blinking text cursors, or CSS animations on the page force a full, highly expensive compositor repaint of the WebGL region.

The reporter (@thesohamdatta) attached a screen recording showing the sustained GPU load.

Scope

This implements solution #1 from the issue (isolate the WebGL canvas from backdrop-filter), which is the actual compositor root cause and needs no product decision. --glass-bg is rgba(0,0,0,0.42), so bg-black/40 reproduces the surface tint without the blur; border-white/[0.08] + rounded-2xl match the existing card idiom already used across the renderer.

I intentionally left the graph's R3F loop alone. The issue's solution #2 assumes frameloop="demand", but BrainGraph.tsx deliberately uses frameloop="always" to drive its continuous pulsing/shine animation — reworking that is a separate, design-affecting change and out of scope here.

Verified

• npm run typecheck:web (tsc) — passes clean.
• eslint on the touched file — no new errors/warnings introduced (only pre-existing ones remain); the added lines are prettier-conformant.
• Not exercised in a running Windows build (no Windows environment available here), so the runtime GPU improvement is UNVERIFIED end-to-end — but the change is a self-contained CSS-class swap that directly removes the backdrop-filter the issue identifies as the cause.

Auto-generated from issue feedback by the mini issues-improver. Review before merge.

[cubic-dev-ai]

No issues found across 1 file

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[Git-on-my-level]

Approving. Clean, well-scoped fix — the diagnosis (WebGL canvas layered over backdrop-filter forces compositor re-blend on every repaint) is correct and verified against globals.css. bg-black/40 faithfully reproduces --glass-bg (rgba(0,0,0,0.42)), rounded-2xl is preserved, and leaving frameloop="always" alone is the right call given the continuous pulse animation.

Two immaterial notes for completeness:

1. The new wrapper drops .glass's box-shadow, which has no visible effect here since the graph fills the card.
2. border-white/[0.08] is marginally lighter than .glass's rgba(255,255,255,0.10) border — consistent with the existing glass-subtle idiom.

Thanks for the clear write-up and the link to issue #8438.