ODrawer suppresses focus-on-open for drawers with no form field or primary button

Summary

ODrawer cancels reka-ui's focus-on-open and then, for any drawer whose content is neither a form field nor a primary footer button, focuses nothing. Focus stays where it was, so a keyboard or screen-reader user gets no indication the drawer appeared and no way into it except tabbing blindly through the page behind.

This is a shared-component defect, not specific to one feature.

Steps to reproduce

1. Alerts → create two scheduled alerts and a composite over them.
2. In the list, open the child's ⋮ menu → Delete → OK. The delete is refused and the Composite references drawer opens.
3. Without touching the mouse, press Enter.

Expected: focus is inside the drawer (on its close control), so Enter dismisses it.

Actual: focus is still on the alert-list search input behind the drawer — document.activeElement is INPUT[data-test="alert-list-search-input-field"] — so Enter does nothing to it.

The alert settings help drawer behaves the same way: read-only content, no primary action, focus never enters.

Cause

web/src/lib/overlay/Drawer/ODrawer.vue, handleOpenAutoFocus:

function handleOpenAutoFocus(event) {
  event.preventDefault();          // cancels reka-ui's own focus placement
  nextTick(() => {
    // 1. first input/textarea inside the drawer BODY
    // 2. else primaryBtnRef
  });
}

Both fallbacks can miss at once: the body query matches only input/textarea, so a drawer of buttons, links or read-only content matches nothing; and primaryBtnRef is attached to a button rendered v-if="primaryButtonLabel", so a drawer with no primary action has no ref. When both miss, preventDefault() has already run and no .focus() follows — focus is actively suppressed rather than merely unassigned.

Drawers that happen to contain a text field or declare a primary button are rescued by accident, which is why this went unnoticed.

Why autofocus does not save it

CompositeReferencesDrawer puts autofocus on its close button. The bare HTML attribute is not dependable for content inserted after parse — it held in local runs and never fired in CI, which made the symptom look like flakiness rather than a defect.

Suggested fix

Only preventDefault() when a target will actually be focused, or add a final fallback: a consumer-declared [autofocus] element, then the panel itself with tabindex="-1" (what reka-ui would have done). Consumers can then drop the autofocus attribute.

E2E guard: A6b in tests/ui-testing/playwright-tests/Alerts/alerts-composite-list.spec.js.