Restore horizontal scrolling for the dashboard job table (regression of JENKINS-73695)

[Anexus5919]

Fixes #27198

#26863 removed the .app-project-status-table { width: 100%; overflow-x: auto; } rule (added by JENKINS-73695 / #9667) while lib/hudson/projectView.jelly still wraps table#projectstatus in that class, so the dashboard job table lost its horizontal scroll container. On current master a table wider than the page is simply clipped at the page frame with no way to reach the hidden columns.

Investigating the fix showed that reinstating the deleted rule alone is NOT sufficient under the new layout, because there are two cooperating causes:

1. The scroll container rule is gone (the obvious one).
2. On pages whose sidebar contains widgets (the default dashboard has Build Queue and Build Executor Status, which emit .pane-frame/.pane), .app-page-body takes its overflow-y: auto branch and .app-page-body__contents has no overflow of its own. As a grid item it then keeps its default min-width: auto, so a wide table inflates the 1fr grid track itself past the viewport before any wrapper can act; the wrapper is laid out at the blown-out width and overflow-x: auto has nothing to scroll. With the rule re-added and nothing else, the geometry is unchanged and the table is still clipped.

This PR therefore makes two CSS-only additions in src/main/scss/base/_layout-commons.scss:

& > .app-page-body__contents {
  ...
  min-width: 0;
}

.app-project-status-table {
  width: 100%;
  overflow-x: auto;
}

The min-width: 0 guard lets the contents track shrink to the available space so scroll containers inside it work; the reinstated rule restores the table's scroll container. No Jelly changes are needed, so every consumer of t:projectView (classic dashboard, experimental dashboard, the Computer and Label pages, folder views, and dashboard-view plugin portlets) inherits the fix.

Notes for reviewers:

• The min-width: 0 guard applies to all widget-bearing pages (job pages match the same :has branch through the Build History card). This is strictly no-worse: previously over-wide content inflated the track and was clipped unreachably; with the guard it either fits or scrolls inside its own container.
• Why this slipped through Standardise experimental Jenkins pages, make the side panel independently scrollable + make the build bar sticky #26863 review: core's own table content is protected by Functions.breakableString (job names get a break opportunity before every punctuation character and inside every run over 20 characters), so a stock instance with default columns never overflows. The bug needs plugin-contributed list-view columns with unbreakable content (version strings, hashes, URLs), which is exactly the scenario of the original JENKINS-73695 reports, or narrow windows combined with extra columns.
• Independent of Prevent nodes table from overflowing the page in the new Manage Jenkins UI #27197 (Nodes page fix): different hunks in the same file, no textual overlap, both merge cleanly in either order. Once both land, a small follow-up could unify the dashboard wrapper onto the generic .jenkins-table-wrapper class that Prevent nodes table from overflowing the page in the new Manage Jenkins UI #27197 introduces.
• The regression exists only on master (2.577-SNAPSHOT); 2.576 and earlier are unaffected. If this merges before the 2.577 cut the regression never ships, which is why the proposed category is skip-changelog; if it misses the cut, please switch the label to regression-fix.

Testing done

• stylelint and prettier pass on the changed file; the webpack production build compiles and the generated bundle contains both rules.
• Manually tested on a local build (mvn -am -pl war,bom -Pquick-build clean install, mvn -pl war jetty:run) with a reproduction matching the original JENKINS-73695 scenario: the extra-columns plugin's Description column added to the default view, and jobs whose description contains a 200-character unbreakable token:
  • Before the fix (master): the description column is clipped at the page frame at any window width, no horizontal scrollbar exists, and the clipped columns cannot be reached.
  • After the fix: the table has its own horizontal scrollbar directly beneath it; all columns including the wide description are reachable by scrolling the table alone, while the sidebar widgets, view tabs, and page frame stay fixed; verified at maximized (1920px) and 900px viewports.
  • Regression checks: column sorting works inside the restored scroll container, vertical page scrolling is unchanged, and job pages (which share the min-width: 0 guard via their Build History sidebar) render normally.
• No automated test is included because the change is presentational CSS; this matches the precedent of [JENKINS-73695] BUG: Dashboard shows white space on certain width space >900px #9667, which introduced the original rule.

Video Reference of the fix (UI changes only)

Screen.Recording.2026-08-06.092142.mp4

Proposed changelog entries

• Restore horizontal scrolling for the job table on the dashboard when it is wider than the page.

Proposed changelog category

/label skip-changelog,web-ui

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@janfaracik

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

[Anexus5919]

This pull request is complete and tested. It is opened as a draft only because of the GitHub limit on open pull requests for contributors without write access. I will mark it "Ready for review" as soon as a slot frees. Reviews and feedback are very welcome in the meantime. 🙏🙏

@janfaracik