docs: what OpenMapClassic is for, and why the canvas is grey between zoom steps

Two recordings made the target concrete: one continuous stitched world,
wheel from Azeroth through continent, zone, city, dungeon floor, no mode
change and no seams. Ours navigates correctly -- breadcrumb coordinates,
lore panel, Find me, zone crossing -- and draws the continent step, and
is grey everywhere between.

Grey is "the tile files were never asked for": PlaceTiles stores
tex.omFile instead of setting it, and ShowZone only queues it when
inView[mapID] == true, which S.Cull writes from a view box built out of
GetCurrentScrollX/Y, GetCanvasScale, the container's size and
GetMapArtLayers(947). Four of our verbs and one constant art size decide
whether a zone's art is ever loaded.

Also records the third BetterCharacterPanel port edit: the stats column
pinned to the panel's own backdrop, so the overflow is reached by
scrolling inside the window instead of hanging over its edge -- window
359, content 699, needs 340, bar reaches 340.

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

docs/ADDON_COMPAT.md

@@ -2787,8 +2787,60 @@ Mirrored at `Addon_Ports/bettercharacterpanel_port/`, both one-liners, both the
   `contentFrame:SetHeight(yOffset)`. The edit keeps the addon's own measure and drops only the
   fudge.
 
-What is left of "the info is bigger than the frame" is the addon's own arithmetic and is not a
-client fault: `BCPPFUICharacterInformationFrame` is `PaperDollFrame:GetHeight() + 19 - padding` =
-**522**, while `BCPPFUIUnifiedBackdrop.backdrop` is `512 - 10 - 72` = **430**, so the stats column
-stands 46 units proud of the panel at the top and 46 at the bottom. `PaperDollFrame` is
-`setAllPoints` to `CharacterFrame` in the realm's own XML, so the 512 it is derived from is right.
+- **A third, after grom said what he wanted**: the stats column stood 46 units proud of the panel
+  at the top and 46 at the bottom, because `BCPPFUICharacterInformationFrame` is
+  `PaperDollFrame:GetHeight() + 19 - padding` = **522** while `BCPPFUIUnifiedBackdrop.backdrop`
+  — the panel a player can see — is `512 - 10 - 72` = **430**. `PaperDollFrame` is `setAllPoints`
+  to `CharacterFrame` in the realm's own XML, so the 512 it derives from is right and this is the
+  addon's own arithmetic. He asked for the overflow to be put **inside** the window rather than
+  for the window to grow, which is one anchor: the info frame is pinned to the backdrop's own top
+  and bottom. Nothing is lost, because the scroll frame is two-corner anchored to it — measured
+  after: window 359, content 699, needs 340, bar reaches 340.
+
+
+## What OpenMapClassic is for, and where ours stands
+
+Two recordings, side by side, are what finally made the target concrete, and it is worth writing
+down because it is not "a map addon with extra buttons".
+
+**The target** (`HOW_openmap_should_work.mkv`, a retail-era client): one continuous stitched world
+on a single canvas. The wheel runs from the whole of Azeroth, through a continent with its ocean
+and neighbours drawn, into a zone, into a city, into a dungeon floor, with no mode change and no
+seams — zones shaded by level, the sea responsive at the border, a search box and a quest/zone
+list down the right, and an options page for how much detail each zoom shows (minimap detail up
+close, minimaps in the gaps, caves underground, icon sizes, a frame-rate cap).
+
+**Ours** (`Openmap_NOW.mkv`): the structure is alive and the art is not. Navigation works — the
+breadcrumb coordinates track the cursor across `Dun Morogh 44.2, 53.6` → `Badlands 63.3, 23.5` →
+`Grim Reaches`, the Zone Lore panel follows the zone, the "Find me" tooltip comes up, zooming out
+crosses zones. At the **continent** step the art draws correctly. Everywhere between zone and
+continent, the canvas is grey.
+
+Grey, specifically, is "the tile files were never asked for". OpenMapClassic loads a zone's art
+lazily: `PlaceTiles` stores `tex.omFile = file` instead of setting it (`Map/Stitch.lua:345`), and
+`ShowZone` only queues a texture when
+
+```lua
+near and drawn and inside and (detailLive or Live.seen) and tex.omFile and not tex.omQueued
+```
+
+where `inside = inView[mapID] == true`, and `inView` is written by `S.Cull(u0, v0, u1, v1)` —
+which is fed, through `Close.lua`'s `S.SetView`, from **our** canvas:
+
+```lua
+local u, v = ToWorld(mapID, sc:GetCurrentScrollX(), sc:GetCurrentScrollY())
+S.SetView(u, v, sc:GetWidth() / 2 * pu, sc:GetHeight() / 2 * pv, zoom * DetailK(), zoom)
+```
+
+with `PerPx`/`DetailK`/`FitPx` all over `S.Size()`, which is `C_Map.GetMapArtLayers(947)` =
+1002x668. So every number that decides whether a zone's files are wanted comes from four of our
+verbs — `GetCurrentScrollX`/`Y`, `GetCanvasScale`, the container's size — and from one art size
+this client answers as a constant.
+
+One thing on that path is already fixed: the canvas was sitting at scale **1.0 while OpenMap's
+whole ladder is 0.0125 to 0.899**, so the view was outside the ladder before a wheel was touched.
+That is the previous section.
+
+The next step is to instrument `inView` and `cullBox` against those four verbs on a real open, and
+find which of them hands OpenMap a view box no zone is ever inside. This is a feature, not a
+defect — it will take its own session, and saying otherwise has not served anybody.