browser-actionability-debuglisted

# Browser Actionability Debug ## Workflow 1. Reproduce the failure with a real browser action, not only DOM existence. - Prefer normal `locator.click()` first so the browser reports what intercepts the pointer. - Read the full call log. If it names an intercepting element, treat that as evidence. 2. Separate visibility from actionability. - `visible` can still be blocked by an overlay, `opacity: 0`, parent `pointer-events: none`, a splash screen, or an element with higher stacking order. - Inspect `elementFromPoint()` at the target center and compare it to the intended button/input. - Capture computed `opacity`, `visibility`, `display`, `pointerEvents`, and bounding boxes for the target and its stable ancestors. 3. Check lifecycle gates before changing CSS. - If a splash/loading/transition component exists, wait for the lifecycle signal that makes the app interactive, such as overlay detached or app shell `pointer-events: auto`. - Do not fix a test by using `force: true` unless the user specifically needs to bypass hit testing. It can hide real UX bugs. 4. Fix at the correct layer. - If the overlay should still be active, update the test to wait for the overlay to detach. - If a decorative canvas or visual layer should never capture input, set `pointer-events: none` on that visual layer. - If app content is intentionally disabled until boot, do not make underlying controls clickable before boot unless that is a product decision. 5. Verify c