[carrdylan52]

Seven ordered commits that extend the PC mouse to menus that still needed the pad or keyboard. Most stand alone, but the costume drag builds on the costume targets. They share menu_mouse*.cpp, menu_world.cpp, options/rows.cpp and docs/PC.md.

Costume menu rows and arrows
Before: the costume selection screen ignored the mouse.
After: hovering a Hat, Clothes or Shoes row, OK, or Monica's Exit selects it with the cursor sound, and a click confirms it as Cross does. A click on a row's left or right arrow steps that slot through retail's own loading and equip handling. A click on the slot's label does not change the costume. OK and Monica's Exit keep their normal confirmation.
How: CostumeMouse (port/src/menu_mouse_menus.cpp) runs from CMenuKeyFunc::CheckSelectKey in MENU_MODE_COSTUME. Its rows match the drawn list artwork, and the arrow targets cover the arrows' full six-unit swing. An arrow click replaces that tick's Cross with Left or Right. MenuCosPtr and MenuCosutumeLoadPhase are exposed through stubs/menuchr.hpp.
Tests: there is no unit test. Checked with a headless replay at 1280x960 from --jump title: hovering selects the Shoes row and then OK, and an arrow click swings the arrows. A new save owns one costume per slot, so the costume itself cannot change there.

Costume character turn and zoom
Before: only the right stick turned and zoomed the costume model.
After: right of the costume lists, a left drag turns the character and the wheel zooms it once the model has loaded. Both use the stick's rotation and 4 to 21 depth range. The wheel steps the rows only while the pointer is over one of them.
How: CostumeModelMouse calls AddRotationCharaY at 0.03 radian per unit of drag, so 100 units turn the model half way round. Each wheel notch moves the depth as three ticks of a full stick do, clamped to retail's range. The drag is a MenuMouseDrag owned by the costume menu that started it. It starts only on a fresh press over the model while the model can take input. Release, a load, a question or step change, the pointer hiding, a reopened menu or a skipped tick ends it, so a button held through any of those turns nothing until it is pressed again.
Tests: MenuMouseDrag.TurnsOnlyAfterAFreshPressOverTheArea, MenuMouseDrag.AHeldPressDoesNotCarryThroughALoad, MenuMouseDrag.AQuestionOrMissedTicksNeedAFreshPress and MenuMouseDrag.ReleaseOrAReopenedMenuEndsTheDrag. Checked with a headless replay: a 200-pixel drag turns Max to face away, two notches bring him closer, and a wheel notch over the rows steps the selection.

Yes/No highlight
Before: with the mouse, Yes/No boxes showed the retail hand at the selected button, which the pointer replaces, so nothing marked the choice a click would take.
After: while the mouse pointer is visible, the selected button is drawn once with the costume menu's selected tint (164 in place of 128). Controller input keeps the retail artwork and hand, and the dialog fade is unchanged.
How: ClsMes::SetSelectCursorPos records the choice when the window is a Yes/No box that is fully shown and the pointer is visible. The DrawYesNo override tints that one sprite and clears the record.
Tests: MenuCursor.YesNoMouseTintsEachChoiceOnceAndControllerKeepsRetailColor. It compares the sprites with the choice positions directly, so it does not depend on the screen offset an earlier test left behind.

Menu pointer speed and acceleration
Before: captured mouse motion reached the menu hand as raw counts, with the OS pointer acceleration off, at one window pixel per count. That is slow on large windows.
After: the hand has its own speed, 150% by default, and an optional acceleration, on by default. Motion of up to four counts a tick stays linear, and a smoothstep doubles the gain by 28 counts. Camera look keeps input.mouse_sensitivity. An uncaptured hand still follows the desktop cursor 1:1.
How: MenuMouseGain scales MovePointer's units when the mouse is captured. This adds two PC SETTINGS > Controls rows, Menu pointer speed (input.menu_pointer_speed, 0.25 to 4) and Menu pointer acceleration (input.menu_pointer_acceleration), saved in config.json and documented in docs/PC.md.
Tests: MenuMouse.PointerGainKeepsFineMotionLinearAndDoublesFastMotion, and the PC options row tests. The rows appear on the Controls page in game. How a captured pointer feels has not been checked: input scripts never capture the mouse, so the gain only runs in the unit test.

Floor Info click enters the floor
Before: on the dungeon Floor Info screen only the drawn Move label took a left click, so clicking elsewhere did nothing while Space worked.
After: a left click elsewhere on the Floor Info screen enters the floor as Cross does. The help labels (Move, Cancel) still act at once. For the first 20 ticks after the screen opens, a click that is not on a label is still taken as the second click of the double click on a room, so it does not travel.
How: FloorScreenMouse (port/src/menu_mouse_floor.cpp) checks the help labels first. It then notes the tick the information opened, and within 20 ticks it clears the click. Afterwards it lets the click through as the language's confirm.
Tests: there is no unit test. Checked with a headless replay on Underground Channel: a double click opens the information and stays there, and a click about 95 ticks later enters the floor.

Build Up list on the spread Item page
Before: the Build Up rows were hit-tested with the raw pointer, but the board is drawn with the left panels. On a wide window, hover and clicks missed every row, and the retail hand was drawn far right of its row.
After: hovering a target's name board, or the gap before it where the retail hand points, selects the target with the cursor sound. A click on a row sends Cross, "???" rows included, so retail accepts or refuses it. Clicks beside the rows do nothing, Mouse2 backs out and the wheel steps the selection. The retail hand stays beside its row.
How: the rows come from the drawn name positions (MenuMouseBuildUpRows, which the Monster Transform class list now shares) and are hit through the Item page's retail-layout pointer. The hand takes the selection's side in CursorFrameShift.
Tests: MenuMouse.BuildUpRowsCoverEachDrawnNameBoard, ItemMouse.BuildUpClicksConfirmOnlyOnRowsAndRightClickBacksOut and MenuWorld.BuildUpHandTakesTheSelectionsSide. tools/input/item-build-up-mouse.input replays the list at 1920x1080.

Item page left panel up to the split
Before: on a wide window the view pages move whole with the left spread, but the pointer was mapped back through the band where the retail cursor eases across. Parts of the left panel within 40 units of the split, such as Max's second weapon, could not be hovered or clicked.
After: the pointer is mapped by where the panels are drawn. Left of the left spread's edge it maps to the left panels, right of the bag's spread it maps to the bag, and the gap between them behaves as before.
How: SpreadPointerX (port/src/menu_world.cpp), called from RetailPointerX.
Tests: MenuWorld.SpreadPointerReachesLeftPanelPartsUpToTheSplit. Checked at 1920x1080: hovering the Trumpet Gun selects it and shows its description.

Test run
Built at this branch's head with master's tools/kazarov (14164f13), Windows x64 Release. The full darkchronicle_tests run has the same 28 failures as master. These are GPU, file-system, audio and environment tests, including a GamePadSingleDebug chord test and a TownEyeCamera test. There is one extra failure, MenuDrawGrab.GrabRoundTrip, a GPU test in code this branch doesn't touch, which passes on each of three runs on its own. The 158 PcOptions, MenuMouse, MenuCursor, ItemMouse, MenuWorld, Config and costume tests all pass. Separately, GamePadSingleDebug tests fail intermittently under parallel ctest on both this branch and master, and pass when run alone. GeoramaParts.PaintedFencesMatchRetailRecursion fails now and then on master too.