A tooltip Lua sized itself kept being re-sized out from under it

benilla auto-sizes a GameTooltip in a pre-pass of every resolve, because
that is where the text measures are. The reference re-sizes one only from
its own content verbs and from Show: 0x530640 has six call sites
(0x52ad59, 0x52b029, 0x52e5ae, 0x52f869, 0x530615, 0x530aad), all inside
the tooltip code and none in the frame pump. So a SetWidth/SetHeight
written after that call stands, and ours was overwritten on the next frame.

ATSW2's recipe tooltip is the case grom hit: it Show()s, then sizes the
plate from its own line count and a column width floored at 350. Losing
that width collapsed the backdrop to the one blank line it pushes through
our AddLine and dropped every right column, anchored RIGHT -10 to the
plate, on top of its left column -- "Required reagents:" and
"Bags Bank Alts" sharing a pixel column in his screenshot.

TooltipState::authored_size: set by SetWidth/SetHeight through the
existing note_authored_size, cleared by any content change, by
SetMinimumWidth/SetPadding, and by Show. layout_tooltips skips a plate
that carries it.

Clearing it on Show matters: pfUI and pfQuest both SetWidth the shared
GameTooltip *before* Show, where the reference overwrites it -- honouring
those would pin every later hover at 180 or 100 px. Two tests pin both
halves.

Measured, driving ATSW2's own OnEnter: plate 350.0 x 81.7, the two
columns 232 px apart.

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

docs/ADDON_COMPAT.md

@@ -4551,3 +4551,103 @@ vignetted by `ATSWBackgroundShadow`) — the one piece of this window version 1
 for. **Hidden, not blanked**, because the addon re-sets the texture on every open and every
 profession switch; `Hide` survives both, and a `hooksecurefunc` on `ATSW_UpdateBackground` is belt
 and braces. Nothing anchors to either texture, so nothing moved.
+
+## A tooltip the addon sized itself was re-sized out from under it every frame
+
+grom, with a screenshot: *"the tooltip box when using atsw2 is not drawing correctly for some
+reason."* In the shot the plate's border wraps the recipe's name and stops; the rest of the
+tooltip's text hangs outside it over the window, and one line is two strings drawn on top of each
+other — `Required reagents:` with `Bags   Bank   Alts` sitting on it.
+
+Both are one defect, and it is ours.
+
+### The rule the reference keeps
+
+A `GameTooltip` auto-sizes from its lines in `0x530640`, which measures each line (`0x772890`) and
+writes the plate. Scanning `.text` for `call` relocations to it finds **six** call sites —
+`0x52ad59`, `0x52b029`, `0x52e5ae`, `0x52f869`, `0x530615` and `0x530aad` — all inside the tooltip's
+own code, and the last of those is `Show` (`0x530a80`). **None is in the frame pump.** So the
+reference re-sizes a tooltip when its content changes and when it is shown, and at no other time: a
+`SetWidth`/`SetHeight` written after that call stands until the next one.
+
+benilla auto-sizes in a pre-pass of every `resolve` instead (`script::tooltip::layout_tooltips`),
+because that is where the text measures are. That is a fine place to *compute* it and the wrong
+rule for *when*: the pre-pass overwrote the explicit size on the very next frame. Ten lines of Lua
+prove it on their own, no addon involved:
+
+```
+tip1  SetWidth/SetHeight after Show   immediately 350.0 x 170.0 | a few frames later  23.8 x 33.3
+tip2  SetWidth/SetHeight before Show  immediately 350.0 x 170.0 | a few frames later  23.8 x 33.3
+```
+
+ATSW2 builds its recipe tooltip by hand — its own line pool, its own `AddDoubleLine`, a
+`ClearLines` that shadows ours — and sizes the plate itself at the end:
+`Tooltip:Show()`, then `SetHeight(NumLines * 18 + 12 - …)`, then `SetWidth(MaxLineWidth)`, which is
+floored at 350 (`AdvancedTradeSkillWindow2.lua:5913-5920`). Losing that width is both symptoms at
+once: the backdrop collapses to the one blank line the addon pushed through our `AddLine`, and
+every right column, anchored `RIGHT, -10` to the plate, lands on top of its left column.
+
+### The fix
+
+`TooltipState::authored_size`: set by `SetWidth`/`SetHeight` through the existing
+`note_authored_size`, cleared by any content change (`clear_content`, `append_line`), by
+`SetMinimumWidth`/`SetPadding`, and by `Show`. `layout_tooltips` skips a plate that carries it —
+size and right-column flush both, since the reference's resize is all-or-nothing and simply does
+not run again.
+
+Clearing it on `Show` is not a detail. pfUI (`modules/addons.lua:245`) and pfQuest
+(`config.lua:634`) both call `GameTooltip:SetWidth(…)` *before* `Show`, where the reference's resize
+overwrites it — those calls are no-ops on a real client, and honouring them would freeze the shared
+`GameTooltip` at 180 or 100 px wide for every hover afterwards. Two tests pin both halves, and
+`unmeasured_lines_hold_declared_size` already covered the third case (a declared size holding until
+the measures land).
+
+Measured after, driving ATSW2's own `OnEnter`: plate **350.0 x 81.7**, `Required reagents:` at
+x=566 and `Bags   Bank   Alts` at x=798 — 232 px apart, where before they shared a pixel column.
+
+### The right-hand pane was black text on a dark panel
+
+*"can we make the font on the right like yellow like the title or white so it's readable?"*
+
+Measured rather than guessed — `GetTextColor()` on each string of that pane:
+
+| string | colour | |
+|---|---|---|
+| `ATSWRecipeName` | `0/0/0` | the item's name, 17 pt, no outline |
+| `ATSWTool1Text` | `0/0/0` | the tools line |
+| `ATSWCostText`, `ATSWCraftDescription` | `0/0/0` | |
+| `ATSWToolsLabel`, `ATSWReagentsLabel` | `1/0.82/0` | already right |
+| `ATSWReagent1Title` | `1/1/1` | |
+
+They are **black** by the addon's own design — `ATSWFont` and `CostFont` declare
+`<Color r="0" g="0" b="0"/>` and the tool template's `<NormalFont>` does too — because the addon
+paints this pane over its own light parchment. That parchment came off last round at his request,
+so the black now sits on a dark pfUI backdrop. The skin repairs what the skin broke: the name goes
+yellow like the title, the rest white.
+
+The tools line needed more than a colour write, because it has three writers: `ATSW_ShowRecipe`
+paints it `SetTextColor(R, 0, 0)` where `R` is 1 only when the tool is **missing**, the template's
+`OnEnter` paints it white, and its `OnLeave` paints `(this.R, 0, 0)` back. Rather than chase all
+three, the string's own `SetTextColor` is wrapped to send black to white and leave every other
+colour alone — so a tool you lack is still red, which is the only thing that colour carries.
+
+### A border for the task list
+
+*"would also love to see some sort of border around the queued task box because its a little hard
+to distinguish right now."*
+
+`ATSWTaskScrollFrame` is the box's geometry (L=625 R=981 T=375 B=260 against a window of L=279
+R=1047 T=722 B=210) but it is **not** the rows' parent and it is not shown: version 2 scrolls the
+list itself and parents every `ATSWTask%d` to `ATSWFrame`, exactly as it does with the recipe rows
+and `ATSWListScrollFrame`. A backdrop on a hidden frame draws nothing, so the panel is its own
+frame anchored to that rect, held one frame level below the rows so it sits behind them.
+
+### Driving ATSW2 in a capture needs version 1 out of the way
+
+Both addons are installed and **both use the `ATSW` prefix** — `ATSWFrame`, `ATSWRecipe1`,
+`ATSW_RECIPES_DISPLAYED`. A capture loads every folder under `AddOns/` regardless of what the
+player has enabled, so version 1 took the globals and `getglobal("ATSWRecipe1")` answered nil while
+a perfectly good trade-skill window was on screen — version 1's. `BENILLA_HOME=<scratch>` with an
+`AddOns/` of symlinks to every folder but `AdvancedTradeSkillWindow`, and a `saved` symlink beside
+it for `WOW_CAPTURE_SAVED`, gives a deterministic version-2 run without touching the player's
+install.