Cap content-area height on every page, fix scroll bugs, sidebar accordion

- Apply the taskbar's max-height/overflow-y:auto treatment to
  #wpbody-content unconditionally, so tall native/Aurora pages (Add
  Plugins, Add User, Profile, Fonts, file editors, Settings, Activity Log,
  Database Explorer, Comments) scroll internally within their frame
  instead of growing past the viewport and scrolling the whole document.
- Fix a Chrome scroll-anchoring bug this surfaced on Add Plugins (page
  loaded scrolled ~1700px into content instead of at the top) via
  overflow-anchor: none.
- Fix a phantom document-level scrollbar with dead space below the frame
  by locking html/body's own overflow, since the sidebar/toolbar are fixed
  and content is only ever meant to scroll internally.
- Make the sidebar's native-menu sections a single-open accordion:
  expanding one now collapses whichever else was open.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

app/src/shell/shell-frame.css

@@ -103,6 +103,18 @@ html.aurora-ready body {
      background instead of a seam between "sidebar" and "page". */
   background-attachment: fixed;
   font-family: var(--aurora-font-family);
+  /* The sidebar/toolbar are position:fixed and every page's real content
+     now scrolls internally within its own frame (#wpbody-content or
+     .aurora-dashboard-frame, both capped to the viewport with their own
+     overflow-y: auto below) — so the document itself is never meant to
+     scroll. Some native pages (Add Plugins' plugin-card grid is the one
+     that surfaced this) leave a huge dead scrollable area at the document
+     level — a WP/browser quirk around lazily-rendered content reserving
+     scroll space against the page rather than the inner container — which
+     showed up as being able to scroll the whole window down to a big
+     empty gap below the frame. Locking the document's own scroll removes
+     that dead space outright, regardless of what's causing it. */
+  overflow: hidden;
 }
 
 /* !important here defeats WordPress's own responsive #wpcontent margin
@@ -196,6 +208,24 @@ html.aurora-ready #wpbody-content {
   margin: 16px var(--aurora-gutter-r) 24px 24px;
   padding: 32px;
   min-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
+  /* Cap the card's own height to whatever's left below the toolbar and let
+     *it* scroll internally, instead of growing to fit tall native pages
+     (Comments, Plugins, Add User, Settings, Activity Log, Database
+     Explorer, ...) and forcing the whole document to scroll — the sidebar/
+     toolbar are fixed, so a tall #wpbody-content just meant a lot of empty
+     scroll distance below the fold with nothing visibly moving except the
+     content. Same fix as the taskbar-present case below, just unconditional. */
+  max-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
+  overflow-y: auto;
+  /* Chrome's scroll anchoring tries to keep whatever's in view visually
+     stable when content shifts above it. Several native pages (Add Plugins'
+     plugin-card grid, most visibly) render their real content via JS well
+     after the initial paint, inserting it above stuff that was already
+     visible in this now-scrollable box — anchoring then "corrects" by
+     jumping scrollTop down to compensate, landing the page scrolled to
+     the middle/bottom on load instead of the top. Opting this container
+     out of anchoring is the standard fix for that class of bug. */
+  overflow-anchor: none;
   box-sizing: border-box;
   /* WP core sets #wpbody-content { float: left; width: 100% }, which (with
      box-sizing left alone) ignores the margin above and overflows past the
@@ -250,6 +280,7 @@ html.aurora-has-taskbar .aurora-dashboard-frame {
       var(--aurora-sidebar-gap) * 2
   );
   overflow-y: auto;
+  overflow-anchor: none;
 }
 
 /* The block editor's skeleton is already positioned with fixed insets