Delete Tailwind's half and build the Workbench without it

Plan step 39 (parts 1-3, folded into one commit: PHP tests read the
deleted files directly, so they cannot land apart from it). Tailwind
leaves the whole stack:

- Delete resources/css/tailwind.css, tokens/theme.css and
  tokens/utilities.css. Neither token file declared an --md-sys-*
  custom property of its own (both only referenced tokens declared
  elsewhere), so nothing loses a value; the md-* interaction and text
  classes already mirror utilities.css's declarations exactly
  (foundation/interaction.css, text.css).
- npm uninstall tailwindcss @tailwindcss/vite; vite.config.js drops the
  plugin and its import; composer.json drops the tailwindcss keyword
  (no lock change — keywords are outside Composer's content hash).
- The Workbench now builds one CSS entry, workbench/resources/css/app.css
  (all.css, showcase.css and the scheme; package.css is folded in and
  removed) instead of two, used by ErrorPage::assets() and every
  browser-test probe page's raw @vite() call; the showcase's own pages
  still take their CSS from the bundle route.
- TokensTest and StylesheetsTest: the two facts theme.css and
  utilities.css carried (every scheme role becomes a colour, resolved
  on the element; md-type-* matches the type-* utilities) are asserted
  directly against the scheme and text.css now that there is no second
  copy to cross-check; StylesheetsTest gained a full-tree scan (every
  .css file under resources/css/ is reached from all.css or
  showcase.css, no exclusions left for Tailwind); the Workbench-entry
  test and every "moved out of tailwind.css" assertion updated for the
  single entry and its removal.
- DesignGuard.php's comments and the development skill's setup section
  no longer name the deleted files or a second Tailwind entry.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qwx5USif3wFFmxtHg5U1g9

workbench/resources/css/app.css

@@ -1,11 +1,16 @@
-/* The Workbench's Tailwind entry, for the classes the showcase still writes, with explicit sources
-   so the plans in docs/ are not scanned for class names. tailwind.css brings the theme and token
-   utilities without declaring the tokens a second time. The package's own CSS is package.css, an
-   entry of its own (its header says why); the layer statement is the same in both, so the
-   `material` layers sit between Tailwind's preflight and its utilities whichever loads first. */
-@layer properties, theme, base, material, components, utilities;
-@import 'tailwindcss' source(none);
-@import '../../../resources/css/tailwind.css';
+/* The package's CSS for the Workbench, built the way an application without Tailwind builds it
+   (plan step 39: Tailwind leaves the whole stack): all.css (the foundation, every layout and every
+   component stylesheet), showcase.css (the showcase's own chrome, so a real Vite build — an error
+   page's fallback-free path, a browser-test probe page's `@vite()` — carries it too, even though
+   the showcase's own pages take their CSS from the bundle route instead) and the Workbench's
+   scheme, in the one CSS entry the Workbench now needs. Vite's own CSS pipeline inlines the
+   imports here and keeps a stylesheet several components import once, at its first position — the
+   order an application gets.
 
-@source '../../../resources/views';
-@source '../../../src';
+   Opens with the same layer statement every package stylesheet does, so the `material` layers hold
+   their place whichever file a page links first; an application with no Tailwind of its own needs
+   nothing more than this. */
+@layer material.reset, material.tokens, material.base, material.layout, material.components, material.text, material.visibility;
+@import '../../../resources/css/all.css';
+@import '../../../resources/css/showcase.css';
+@import './material-scheme.css';