Two one-cause clusters: the pet bar never loaded, the auction window never built

**The pet bar, nine tests.** No script errors, and the shelf simply never
drew. PetActionBarFrame had no scripts attached at all: the kit seats a bare
stand-in under that name from the managed-positions pass — which it must,
since the pass does PetActionBarFrame:IsShown() (UIParent.lua:2065) — and the
real frame could never take the name back, a publish to _G being
non-overwriting (0x701bd0). So PetActionBar_OnLoad never ran, showgrid stayed
nil instead of 0, and ShowPetActionBar's `showgrid == 0` gate refused forever.

The kit was loading BonusActionBarFrame.xml, whose ShapeshiftBar_OnLoad calls
that pass, *before* PetActionBarFrame.xml. The realm's FrameXML.toc has them
at rows 83 and 84, the other way round. Loading them in toc order fixes eight;
the ninth asserted stock 1.12's unguarded `Attack ()`, and the realm now wraps
that append in `if ( key ~= "" )`, so the client was right.

Same shape and the same seat list that cost 137 tests through ChatFrame1.

**The auction window, fourteen tests.** The whole Blizzard_AuctionUI load
raised: the realm's rewritten CalculateAuctionDeposit is
`floor(price * (duration/120) * (1 + (maxStack - stackSize) * 0.05) * 0.025)`,
and GetAuctionSellItemInfo answered the reference's six values — 1.12 returns
exactly six — so maxStack was nil and the arithmetic raised out of
AuctionFrameAuctions_OnLoad. The window never built.

It answers eight now: maxStack from the template's stack size, and the link.
Then the realm's own CalculateAuctionDeposit replaces the engine binding, as
it is meant to, which is why that test's numbers move — its fixture also
needed Linen Cloth's real stack of 20, since a missing one reads 1 and makes
the factor shrink below 1 for a two-item stack.

Also recorded, because it changes what every earlier count in this session
meant: `cargo test --workspace` stops at the first failing binary, so the "96
failures" I had been tracking was benilla-app's lib target alone. With
--no-fail-fast the real total was 257; these two clusters take it to 243.
benilla-ui is fully green (2061), and 80 of the rest are the known
benilla-formats data goldens.

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

crates/benilla-ui/src/script/editbox/tests.rs

@@ -1379,15 +1379,21 @@ fn an_editbox_is_born_with_the_ctors_five_regions_ahead_of_its_authored_ones() {
         "typed",
         "region 1 is the ctor's embedded text FontString"
     );
-    // 2..5, the selection quads and the caret, carry no art: benilla paints both host-side.
+    // 2..5, the selection quads and the caret, carry no *file*: benilla paints both host-side.
+    // They answer `GetTexture` with `"Solid Texture"` all the same, because the reference builds
+    // them as colour-set textures and that is what it answers for one (the string is in
+    // `WoW.exe`). Not cosmetic: the idiom for finding a frame's art is to walk `GetRegions` and
+    // filter on `GetTexture`, and a scanner reads **nil** as "no name to match, take this one" —
+    // pfUI's `GetNoNameObject` does exactly that, which is how it came to skin a money box's
+    // caret as its gold coin and collapse the trade window's money row.
     assert!(
         s.eval::<bool>(
             "local a,b,c,d,e = Box:GetRegions() \
-             return b:GetTexture() == nil and c:GetTexture() == nil \
-                and d:GetTexture() == nil and e:GetTexture() == nil"
+             return b:GetTexture() == 'Solid Texture' and c:GetTexture() == 'Solid Texture' \
+                and d:GetTexture() == 'Solid Texture' and e:GetTexture() == 'Solid Texture'"
         )
         .unwrap(),
-        "the selection trio and the caret are blank quads"
+        "the selection trio and the caret are solid quads, and say so"
     );
 }