docs(theme): correct the .btn upstreaming claim — it was not universal

HistorianGateway has no local .btn sizing in either its committed tree or its
sweep branch (only vendored bootstrap.min.css), so the shipped comment and README
naming all five consumers were wrong. Consequence worth stating: HG's bump to
0.4.0+ is a VISIBLE change (buttons shrink to .85rem), not the no-op cleanup it is
for consumers that already carried the block.

ZB.MOM.WW.Theme/README.md

@@ -84,8 +84,14 @@ Served at `_content/ZB.MOM.WW.Theme/…` by the ASP.NET static-web-asset pipelin
 
 **Bootstrap button sizing (new in 0.4.0).** The kit now normalizes `.btn` / `.btn-sm` against its
 0.9rem body via `--bs-btn-*` variable overrides, because Bootstrap hard-codes
-`--bs-btn-font-size: 1rem`. All five consuming apps had written this same block into their own
-stylesheets; **delete the local copy when you bump to 0.4.0** (each carries a comment saying so).
+`--bs-btn-font-size: 1rem`. Several consuming apps had written this same block into their own
+stylesheets; **trim the local copy when you bump to 0.4.0** — trim rather than delete, because a
+local `.btn` may also carry app-specific *shape* declarations the kit does not ship.
+
+**This is not universal — check before assuming your app already had it.** HistorianGateway has no
+local `.btn` sizing at all, so for it the bump to 0.4.0+ is a **visible change** (buttons shrink from
+Bootstrap's 1rem to `.85rem`) rather than a no-op cleanup. An earlier version of this note claimed
+all five consumers carried the block; that was wrong.
 Size buttons by overriding the `--bs-btn-*` variables, never by redeclaring box properties — the
 `.btn-group` seam and radius machinery reads those variables, so a literal `font-size` at equal
 specificity silently reduces `.btn-sm` to a padding-only difference.

ZB.MOM.WW.Theme/src/ZB.MOM.WW.Theme/wwwroot/css/layout.css

@@ -3,10 +3,17 @@
 
 /* ── Bootstrap button sizing ─────────────────────────────────────────────────
    Bootstrap hard-codes --bs-btn-font-size: 1rem, which is oversized against
-   this kit's 0.9rem body. Every consuming app had independently written this
-   same block into its own stylesheet (ignitionoee app.css, OtOpcUa site.css,
-   mxgw site.css, HistorianGateway site.css, ScadaBridge site.css) — it is
-   upstreamed here in 0.4.0, and those local copies can be deleted on bump.
+   this kit's 0.9rem body. Several consuming apps had independently written this
+   same block into their own stylesheets — verified in ignitionoee app.css,
+   OtOpcUa site.css, mxgw site.css and ScadaBridge — so it is upstreamed here in
+   0.4.0 and those local copies can be trimmed on bump.
+
+   NOT universal, despite an earlier claim in this comment that listed all five:
+   HistorianGateway has NO local .btn sizing in either its committed tree or its
+   sweep branch — only vendored bootstrap.min.css. So on 0.3.1 its buttons render
+   at Bootstrap's default 1rem, and its bump to 0.4.0+ is a VISIBLE change (buttons
+   shrink to .85rem), not the no-op cleanup it is for the others. Do not assume a
+   consumer already has this sizing; check before calling a bump cosmetic.
 
    Sized by CSS-variable override ONLY — never by redeclaring box properties.
    Bootstrap's .btn-group seam and radius machinery reads these same variables,