fix(editor): raise floating panels above the sidebars

[lovepixel-git]

Fixes #332.

Root cause

The floating AI assistant shell is z-index: 50. The sidebars are 85. So a docked properties panel wins and the assistant is unreachable without closing or undocking the sidebar first, exactly as reported.

The interesting part is that the convention already exists and these panels just are not on it. The shared FloatingWindow primitive (src/admin/shared/FloatingWindow/FloatingWindow.module.css) is z-index: 90, deliberately above the 85 sidebar tier, and every floating window built on it layers correctly. AgentPanel and PropertiesPanel each hand-roll their own floating shell instead of using that primitive, and both were left at 50.

So this is not "bump the number until the symptom goes away", it is putting the two hand-rolled shells on the layer the shared primitive already defines.

Same bug, second site

PropertiesPanel has it too and nobody has reported it yet: undock the inspector, then open any docked sidebar panel, and it disappears the same way. Fixed here since it is one root cause rather than two problems. Happy to split it out if you would rather keep this to the reported path.

Blast radius

Only the floating rules change. Both docked variants (.floatPanelDocked, .panelDocked) already reset z-index: auto, so docked layout is untouched.

I checked what sits above 90 to be sure nothing important is now covered:

Layer	z-index	Still above?
Code editor panel	95	yes
Inspector StyleSurface	99	yes
Step-up dialog / toolbar dialog	200 / 201	yes
Preview overlay	400 / 401	yes
Spotlight / slash menu / tooltips	9000 / 10000 / 10001	yes

Ties at exactly 90 are the other floating surfaces (FloatingWindow, MediaViewerWindow, the left sidebar's floating rule), which is the correct peer group. Order among them falls to DOM order, which is the same rule that already governs them today.

Two things worth your call

Which behavior you wanted. The issue proposed either "float over" or "split the right sidebar". This does the first, because it is the smaller change and it matches the existing floating tier. Splitting the sidebar is a real layout feature and a different PR.

A token, if you want one. 90 is now written in three places. Extracting something like --z-floating-panel into globals.css next to the existing --z-dropdown: 20 would pin the convention properly. I left it out because that is a broader call about your z-index system than this bug needs, and the values run 1, 2, 30, 50, 85, 90, 95, 99, 200, 400 and one 2147483647, so a real scale is more than a bug fix should decide. Say the word and I will add it.

Tests

No new test. This changes a layer, not behavior, and the assertion that would matter (a floating panel is clickable over a docked sidebar) needs a real browser, so it belongs in the Playwright suite rather than bun test. I did not want to assert a z-index policy you have not stated, but if you would like the convention pinned there is a precedent for a source-scanning gate in src/__tests__/architecture/ and I am glad to add one.

• bun run lint clean
• bunx tsc -b exit 0
• bun run build clean
• bun test 6571 pass, 1 fail

The failure is pre-existing

Bundle size budgets > ContentPage-*.js, 91206 B against a 90000 B budget. Not from this change, and it cannot be: this PR touches two CSS declarations in the site editor, not the content route. I stashed the diff, rebuilt clean main and got the same failure. Worth flagging that it is drifting rather than static, it was 90043 B on main a few days ago and is 91206 B now.