Panel: establish production visual styling and theme contract

Goal

Replace the current mechanically wired Panel stylesheet with a deliberate, usable visual design while preserving the existing Shadow-DOM isolation, renderer/consumer boundaries, and interaction model.

Audit finding

packages/panel/src/styles.ts explicitly states that real dark-theme variables and layout rules remain an open design decision. The current stylesheet only positions the floating trigger and hides the panel region. The rest of the UI therefore relies largely on browser defaults.

The Panel's functional inspection work is now substantially complete: event list, selection, inspector, filtering, search, keyboard navigation, operational controls, session import/export, and the floating trigger all exist. Visual design is now the most obvious unfinished user-facing layer rather than speculative infrastructure.

Investigation first

Before implementation, inspect:

• ADR-0008 theming/deferred decisions
• docs/specs/inspection.md presentation model
• current renderer and Panel component structure
• trigger/overlay lifecycle from Issue #16
• accessibility attributes and keyboard interaction already implemented
• current Playground composition

Define the smallest visual contract for v1, including:

1. Panel placement and dimensions.
2. Event-row hierarchy and severity affordances.
3. Inspector/list relationship and responsive behavior within the overlay.
4. Typography, spacing, borders, surfaces, and focus states.
5. A default dark theme and whether light/auto theme belongs in the same change or should remain separate.
6. CSS custom-property ownership and naming so later theming does not require renderer changes.
7. Contrast/focus requirements for keyboard accessibility.
8. Behavior when the host application has unusual global styles, confirming Shadow DOM isolation remains sufficient.

Use the existing design constraints rather than introducing a UI framework or CSS-in-JS system.

Implementation requirements

• Keep styling inside @devlens/panel.
• Preserve Shadow-DOM isolation.
• Do not move presentation policy into Core or capture packages.
• Do not add framework dependencies.
• Do not change event semantics, Store behavior, or capture behavior.
• Keep the floating trigger functional and accessible.
• Preserve existing data-devlens-* hooks used by tests and lifecycle code unless a change is explicitly justified.
• Add focused rendering/accessibility regression tests for any behavior that styling affects.

Scope boundary

This issue is visual/product design, not a reason to add new Panel features. Specifically out of scope unless the design investigation proves an existing contract cannot support the styling:

• new filtering/search capabilities,
• docking or dragging,
• virtualization,
• keyboard shortcut systems,
• framework wrappers,
• changes to the EventStore/EventBus API.

Light/auto theme may be split into a follow-up if combining it with the first production visual pass would make the contract unnecessarily broad.

Verification

Run the full workspace tests/build, format check, git diff --check, and relevant Playground typechecks. Manually verify the real Playground overlay visually because this issue cannot be validated adequately by DOM assertions alone.

Do not commit until the visual contract and final diff have been reviewed.

Start with packages/panel/src/styles.ts, ADR-0008, docs/specs/inspection.md, and the current renderer and Panel structure. Trace the trigger and overlay lifecycle from Issue #16, then inspect accessibility attributes, keyboard interaction, and the Playground composition before defining the v1 visual contract. Done means reviewed styling that preserves Shadow-DOM isolation and hooks, focused regression tests, passing workspace checks, and manual Playground verification.