Cut duplicated and speculative code across the package

An over-engineering audit of the whole tree, applied in five reviewed
batches. Behaviour stays the same except where UPGRADE.md says otherwise.

PHP: the showcase and error-page stylesheets are prebuilt into
resources/dist by bin/stylesheets.mjs, through Vite's own postcss-import
(first occurrence kept, the order an application's build gives), instead
of Stylesheets::bundle() inlining imports on every request; only the
import walk DesignGuard needs stays. SchemeStylesheet::withProfiles()
replaces three copies of the scheme-plus-profiles loop, material:scheme
leaves spec and contrast checks to the node script that already made
them, and the error page's scheme cache, the hashed view namespace, the
translations path with no lang/ folder and DesignGuard's 1.x-name hints
are gone.

JS: the androidx shape port progress.js and both bin scripts each carried
lives once in resources/js/shapes.js (the generated SVGs are unchanged);
util.js holds ringIndex(), ms(), reopenGuard() and remember(), which
were written out several times; listeners are released through
AbortController; tooltip.js's hoverPopover() serves the rich tooltip too.

CSS: every rule for an element inside the navigation rail queries
`--md-navigation-rail-value` instead of repeating the seven collapsed
conditions under five media branches; badge, alert, progress, slider and
button read one non-inheriting colour-role table (components/color.css);
the dialog chrome, the submenu's popover chrome, the chip's state layer
and touch target, and the visually-hidden inputs use the shared rules
they copied; foundation/tokens.css is folded into foundation.css.

Views: Support\Field and Support\Link replace the error-key, bound-value
and link-attribute blocks copied into the fields and link components;
the timepicker period group, the menu filter and the showcase head are
partials; the datepicker's steppers and entry fields are loops; component
docblocks no longer restate SKILL.md.

Tests and tooling: one dataset-driven ComponentStylesheetsTest replaces
four per-group files, DesignGuardTest and the layout-component tests use
datasets, browser tests share one ready() helper, CSS parsing lives in
ComponentStylesheet alone. docs/audits and the finding IDs citing it are
removed, as are pestphp/pest-plugin-laravel, the unused composer scripts
and check:font; the lint job runs in the feature job, which now installs
node packages so the prebuilt-stylesheet staleness test runs in CI.

Feature suite 1177 passed, Chrome browser suite 299 passed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

resources/css/components/toolbar.css

@@ -15,7 +15,7 @@
  *              8px at its ends and 4px between controls; `vertical` stands it on end
  *
  * Placed over the page, a horizontal toolbar keeps 16dp from the window's edge and a vertical one
- * 24dp, which is M3's minimum for each (N-12).
+ * 24dp, which is M3's minimum for each.
  *
  * On web and large screens a docked toolbar "can be rounded", and dividers can organise its
  * controls into groups: `rounded` does the first from `expanded` (840px), and a divider in the
@@ -23,7 +23,7 @@
  *
  * `<x-button>` and `<x-fab>` draw their own ink from `data-md-color`/`data-md-variant`, not a
  * utility, so a toolbar's recolouring rules — vibrant's icon buttons, a standard toolbar's primary
- * ones (N-13), a docked FAB's flattened shadow — sit in this file's own `material.components`
+ * ones, a docked FAB's flattened shadow — sit in this file's own `material.components`
  * layer like everything else, each more specific than the button.css or fab.css rule it overrides,
  * whichever file an application imports first. The recolouring leaves a disabled button alone, so
  * button.css's disabled colours still apply inside a toolbar.
@@ -82,7 +82,7 @@
     }
 
     /* M3's colour list for a standard toolbar ends "Standard button (Primary)", as the vibrant list
-       ends "Standard button (On primary container)" — the row above (N-13). Both rows name the
+       ends "Standard button (On primary container)" — the row above. Both rows name the
        *standard* button, so a button that fills its own container is left alone: it carries the
        matching label colour (`filled` on-primary, `tonal` on-tone, either selected), and painting
        that label primary put a primary icon on a primary fill — the current page's button in a
@@ -140,7 +140,7 @@
      * A toolbar at the bottom shares the screen region with a navigation bar, so it clears the one
      * <x-scaffold> publishes as --material-bottom-bar, exactly as the FAB and the snackbar do —
      * `max()`, not a sum, because that height already swallows the bottom safe area; without a bar
-     * the safe area alone applies (N-02). A *docked* toolbar and a navigation bar must never be on
+     * the safe area alone applies. A *docked* toolbar and a navigation bar must never be on
      * screen together at all; the offset is the backstop, not a licence.
      */
     [data-md-toolbar-place='bottom'] {
@@ -160,7 +160,7 @@
     }
 
     /* "Horizontal toolbars should have a minimum 16dp margin from the edge of the window. Vertical
-       toolbars should have a minimum 24dp margin" (N-12). */
+       toolbars should have a minimum 24dp margin". */
     [data-md-toolbar][data-md-vertical][data-md-toolbar-place='end'],
     [data-md-toolbar-group][data-md-vertical][data-md-toolbar-place='end'] {
         inset-inline-end: calc(var(--md-sys-measurement-space300) + var(--material-safe-right, env(safe-area-inset-right)));