Motivation

The side info panel on the pull request page does not scroll in the same way as the equivalent panel on the issue detail page. On an issue, the panel scrolls naturally with the page content and settles (sticks) at the top once it reaches the header offset, so the whole panel is reachable by normal page scrolling. On a pull request, the page stops scrolling before the sidebar content is exhausted and the remainder is either trapped behind an inner scrollbar or not reachable at all.

The issue page is the reference behaviour here — it is what the panel is designed to do, and what users have already learned. A PR sidebar that scrolls differently is a usability and consistency defect:

• Narrow, tall viewports and zoomed-in/browser-sidebar layouts are where this bites hardest: sidebar sections like metadata, participants, linked items, and checks get cut off.
• Nested scroll areas are easy to miss with a trackpad or keyboard; users conclude the content is missing rather than scrollable.
• Inconsistency between two pages that render the same component class makes the UI feel unreliable and generates repeat questions.

Current behaviour (pull request page)

• Scrolling the main page content stops while sidebar content is still not fully visible.
• Remaining sidebar content is only reachable via a nested scroll region, which is not obvious and does not respond to normal page scrolling.
• Sidebar content can be clipped entirely on shorter viewports.

Expected / proposed behaviour (match the issue page)

• The side info panel scrolls naturally with the page, exactly as it does on the issue detail page.
• Once the panel reaches the header offset it sticks, and the page continues to scroll underneath it.
• No nested scrollbar is introduced for the side panel; the page is the only scroll container for it.
• All sidebar content is reachable by normal page scrolling at any reasonable viewport height, zoom level, and with a visible browser sidebar.
• Behaviour on the issue page is unchanged — it is the acceptance reference, so any solution must not regress it.

Suggested solution

(Hypothesis — confirm before implementing.) The difference is most likely not the sticky value but the scroll container the panel resolves against: position: sticky is resolved against the nearest scrolling ancestor, not the viewport. On the PR page the side column sits in a full-height layout where an ancestor has non-visible overflow (e.g. overflow-y: auto/hidden with height: 100% / min-height: 0), so the panel sticks relative to that inner box instead of the document.

Two candidate fixes, in order of preference:

1. Remove the clipping context on the PR page so the panel's nearest scrolling ancestor is the document, as on the issue page. Let the content column grow naturally rather than being height-constrained, and drop the non-visible overflow from the ancestors of the side column. This unifies the two pages with the least special-casing.
2. Extract the shared layout used by the issue page — or a single side-panel wrapper that owns the sticky/offset behaviour — and use it from both pages, so the two cannot drift again.

If it turns out the panel genuinely needs an inner scroll region on PRs (e.g. a very long checks list), that should be a deliberate, visible affordance and applied to both pages, not an accidental side effect of the layout.

Acceptance criteria

•  Side panel on the PR page scrolls identically to the issue page, side by side, at the same viewport size.
•  No nested scrollbar for the side panel on the PR page.
•  Panel sticks at the same header offset on both pages.
•  Verified at a short viewport height, at high zoom, and with a browser side panel open.
•  Issue page behaviour unchanged.
•  Keyboard-only scrolling reaches all sidebar content.
•  PR sidebar does not need an intentional inner scroll for pathological content

Notes / out of scope

• Not a request to redesign the PR sidebar content — only its scrolling and positioning behaviour.