docs: correct the correction — absence of a .btn block does not imply the bump restyles

HistorianGateway has no local block AND no Bootstrap button call sites (all 15
buttons use the kit's .rail-btn chassis class), so the kit's .btn rule matches
nothing and bumping it changes nothing visible. My previous correction claimed the
opposite. Checking this needs two greps — declaration AND call sites — which come
apart exactly when an app doesn't use Bootstrap buttons.

ZB.MOM.WW.Theme/README.md

@@ -88,10 +88,19 @@ Served at `_content/ZB.MOM.WW.Theme/…` by the ASP.NET static-web-asset pipelin
 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.
+**This is not universal, and checking it takes two greps, not one.** An earlier version of this note
+claimed all five consumers carried the block. They do not — and the follow-up correction, that the
+missing-block app would therefore be *restyled* by the bump, was also wrong.
+
+| Question | Check |
+|---|---|
+| Does the app declare its own `.btn` sizing? | `grep bs-btn-font-size`, excluding `lib/bootstrap` |
+| Does the app **use** Bootstrap buttons at all? | count `class="…"` values carrying a bare `btn` token |
+
+HistorianGateway answers **no to both** — all 15 of its buttons use the kit's own `.rail-btn` chassis
+class — so the kit's `.btn` rule matches nothing there and bumping it changes nothing visible. The
+first question alone is misleading in both directions: "no local block" does **not** imply "the kit
+now supplies sizing the app was missing."
 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

@@ -8,12 +8,22 @@
    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.
+   NOT universal, despite an earlier claim here that listed all five. Checking
+   whether a consumer carries this block needs TWO questions, and they come apart:
+
+     (1) does it declare its own .btn sizing?   grep bs-btn-font-size (skip lib/bootstrap)
+     (2) does it USE Bootstrap buttons at all?  count call sites carrying a bare
+                                                `btn` token in class="…"
+
+   HistorianGateway answers no to BOTH: it styles all 15 of its buttons with the
+   side-rail chassis class .rail-btn, so it had no block to carry AND the kit's
+   .btn rule matches nothing there. Bumping it changes NOTHING visible — the rule
+   is inert until call sites are converted to Bootstrap.
+
+   Question (1) alone gives the wrong answer in both directions. "No local block"
+   read as "the kit now supplies sizing it lacked" produced a confident warning
+   that its buttons would shrink; they would not, because nothing matches. Ask (2)
+   before telling anyone a bump restyles their UI.
 
    Sized by CSS-variable override ONLY — never by redeclaring box properties.
    Bootstrap's .btn-group seam and radius machinery reads these same variables,

admin_ui_cleanup.md

@@ -246,12 +246,22 @@ foundation branch merges — all branches build independently and compose at mer
    also carry app-specific *shape* declarations that predate the sweep and that the kit does not
    ship; mxgw's carried `border-radius: 5px; font-weight: 500; white-space: nowrap`, and a wholesale
    delete would have silently dropped all three. Diff your block against the kit's before removing
-   **And check whether your app has one at all** — "every app carries this block" was asserted after
-   checking the apps that were convenient to check, and it was false. HistorianGateway has NO local
-   `.btn` sizing in either tree, only vendored Bootstrap, so for it the bump is a **visible change**
-   (buttons shrink from Bootstrap's 1rem to `.85rem`), not the no-op cleanup the note promised. The
-   per-repo check is one grep for `bs-btn-font-size` excluding `lib/bootstrap` — under ten seconds,
-   against a claim that was wrong for 20% of the family.
+   **And check whether your app has one at all — with TWO greps, because one is misleading.**
+   "Every app carries this block" was false (HistorianGateway has none). But the obvious correction —
+   "then the kit now supplies sizing it was missing, so the bump restyles it" — was **also false**, and
+   is the more instructive error. Two independent questions:
+
+   ```bash
+   grep -rl bs-btn-font-size src | grep -v lib/bootstrap          # (1) declares its own sizing?
+   grep -rhoE 'class="[^"]*"' <components> \
+     | grep -cE '(^|["[:space:]])btn([[:space:]]|"|-)'            # (2) uses Bootstrap buttons?
+   ```
+
+   They come apart exactly when an app doesn't use Bootstrap buttons. HistorianGateway answers no to
+   both — all 15 buttons carry the kit's `.rail-btn` chassis class — so the kit's `.btn` rule matches
+   nothing and the bump is invisible there. Zero call sites ⇒ invisible regardless of the block;
+   non-zero and no block ⇒ the restyle warning holds. Ask (2) before telling anyone their UI will
+   change, and note that a "Bootstrap-free" app is precisely the profile that yields zero call sites.
 
    anything: four of the five apps' blocks were pure sizing and safe to delete outright, one was
    not, and the difference is invisible unless you look. Two of the four that were safe deleted
@@ -372,10 +382,18 @@ each time the claim was made in good faith by someone who had genuinely looked a
   granted on a property nobody re-derived. It was a Bootstrap host and *was* affected.
 
 The shape is identical every time: a universal claim, a partial check, and a conclusion that happens
-to be convenient. The fix is not more caution, it is a **cheap per-member check that actually runs** —
-one grep, ten seconds — plus stating the claim's scope honestly ("verified in these three; not checked
-in the other two") when the check hasn't run. Note that all three were caught by someone re-examining
-their own earlier assertion, never by the assertion being challenged.
+to be convenient. The fix is not more caution, it is a **cheap per-member check that actually runs**,
+plus stating the claim's scope honestly ("verified in these three; not checked in the other two")
+when it hasn't. All three were caught by someone re-examining their own earlier assertion, never by
+the assertion being challenged.
+
+**A correction is not automatically safer than the claim it replaces.** The first item above was
+corrected to "HistorianGateway has no block, so the bump restyles it" — which was *also* wrong, for a
+new reason: it had no Bootstrap button call sites either, so the kit's rule matches nothing. The
+correction inherited the original's flaw (one grep, one inference) while feeling rigorous because it
+was a retraction. When you correct a set-wide claim, the replacement needs the *same* evidentiary bar
+you now know the original lacked — and a wrong correction is worse than the wrong claim, because it
+arrives with the authority of a self-caught mistake.
 
 **Record what you could not exercise rather than rounding it up.** HistorianGateway proved 2 of its
 4 truncation sites live and said so: `sf.Error` needs a genuine drain failure, which needs a