/* SURFACE UTILITIES — .db-surface--* / .db-rule--*
   ---------------------------------------------------------------------------
   The prototype alternates section backgrounds page by page, and the SAME
   section takes different surfaces on different pages:

     .db-clients        sand on event-service / corporate-events / about,
                        cream on equipment-rental
     .db-team--rail     cream on event-service / drinks / catering-services,
                        sand on corporate-events / equipment-rental
     .db-cardgrid       sand on drinks, transparent + bottom rule on equipment-rental
     .db-pricelist      sand on equipment-rental, cream on wine-catering
     .db-service-cols   sand on event-service / catering-services, cream on drinks
     .db-faq            transparent on five pages, sand on drinks
     .db-rows           transparent + rule on corporate-events / catering-services,
                        sand and NO rule on event-service

   Baking that into per-section variants would mean a --sand and a --cream twin
   for eight sections. These utilities carry the surface instead, so a section
   stylesheet only states its default and a page overrides it.

   THE DOUBLED CLASS IS DELIBERATE. A section's own rule (`.db-cardgrid`) is
   (0,1,0); so is a single utility class, and section stylesheets load after this
   file in the alphabetical glob in functions.php — so a single class would lose
   on source order. Doubling makes it (0,2,0) and order-independent, the same
   trick core uses for `has-custom-content-position`. */

.db-surface--sand.db-surface--sand   { background: var(--sand); }
.db-surface--cream.db-surface--cream { background: var(--cream); }
.db-surface--none.db-surface--none   { background: none; }

.db-rule--bottom.db-rule--bottom { border-bottom: 1px solid var(--line); }
.db-rule--none.db-rule--none     { border-bottom: 0; }

/* ---------------------------------------------------------------------------
   ⚠️ THE CLIENT DOES NOT TYPE THESE, AND MUST NOT BE TOLD TO (§9.71).

   These five classes are what the build scripts wrote. Everything they do is
   already reachable from the editor's own controls, which is the canonical path
   for anyone working through the admin:

     db-surface--sand    →  Block ▸ Farbe ▸ Hintergrund ▸ **Surface**  (#D9CEC2)
     db-surface--cream   →  Block ▸ Farbe ▸ Hintergrund ▸ **Base**     (#EEE8E2)
     db-surface--none    →  no background set (clear the swatch)
     db-rule--bottom     →  Block ▸ Rahmen ▸ unten, 1px, **Line**      (#BFB8B1)
     db-rule--none       →  no border set

   Both forms render identically and both are supported — a page may carry
   either, and the 77 built pages carry the utility form. There is no cascade
   fight between them: core emits
   `.has-surface-background-color { background-color: … !important }`, so a
   background chosen in the editor beats any section stylesheet's own
   `background`, including the ones in this file. Verified in the rendered CSS,
   not assumed.

   Deliberately NOT registered as block styles. `register_block_style()` emits
   `is-style-<name>` and only one may be active per block, so surface and rule —
   which are independent axes — could not be combined; and it would add a third
   spelling for something that already has two. If these are ever consolidated,
   migrate the content to the native attributes and delete this file, rather
   than adding another layer on top of it.
   --------------------------------------------------------------------------- */