feat(desktop): Alt+wheel to scale the pet, never cropped

[OutThisLife]

Summary

• Alt/Option + scroll over the pet to scale it — same on Mac and Windows. The modifier is required so a plain scroll still scrolls the page underneath (we only preventDefault while Alt is held). Drives the same display.pet.scale path as the settings slider, so the two stay in agreement and it persists.
• Zooms toward the cursor — the pixel under the pointer stays put as the pet grows/shrinks, so it scales in place instead of running off (see Math below).
• Never cropped. The popped-out overlay grows its OS window to fit the pet at any scale, and the new bounds are persisted so it reopens at the right size. The in-window pet re-clamps against its actual size, so growing near an edge can't push it out of view.
• Per-pixel click-through on the overlay. Only solid sprite pixels (plus the bubble / mail button / open composer) are interactive — clicks on the transparent rectangle around the art pass through to whatever's behind, instead of the old bounding-box test.

How it's wired

• usePetZoomGesture — small hook, native non-passive wheel listener, reads live scale from $petInfo, no-ops unless altKey. Emits the new scale plus a { clientX, clientY, ratio } anchor. Used by both the in-window pet and the overlay.
• nextScaleFromWheel (pet-gallery) — pure multiplicative step clamped to the slider range.
• overlayWindowSize (pet-overlay) — single source of truth for overlay window dims at a given scale; used by both pop-out and the live resize.
• electron/main.cjs — set-bounds briefly flips resizable on when the size actually changes (Electron 40 ignores programmatic resize on non-resizable windows on Win/Linux); pure drags untouched.
• Overlay → main scale control message persists through the main window's gateway (the overlay has none).
• pet-sprite canvas opts into willReadFrequently for the per-pixel alpha sampling.

Math — zoom toward the cursor

Standard "zoom about a point": as the sprite scales by ratio = newScale / oldScale, every pixel's offset from the anchor scales by the same ratio. To keep the anchor pixel fixed on screen, move the origin by the growth of that offset. ratio is clamp-aware (it's next / base after clamping to the slider range), so at the min/max bound ratio = 1 and nothing drifts.

In-window pet (origin = the element's top-left pos, anchor = cursor in viewport coords):

posNew = cursor − (cursor − pos) · ratio      // per axis

The (cursor − pos) is the cursor's offset inside the pet; scaling it by ratio and subtracting from cursor gives the new top-left. Result is clamped to the viewport so the whole sprite stays visible.

Overlay (the OS window moves; the sprite is laid out bottom-centered at window-local B = (W/2, H − padBottom) and scales about B):

Let a be the anchor in window-local coords (the wheel cursor; for a slider change with no cursor we fall back to a = B, which makes the term below vanish). The window-local anchor maps to screen screen + a. After scaling, the sprite's bottom-center must land where the anchor's scaled offset still resolves to that same screen point, so the new window origin is:

originNew = screen + a − (a − B) · ratio − Bnew

where Bnew = (Wnew/2, Hnew − padBottom). With a = B this collapses to originNew = screen + B − Bnew, i.e. pin the feet. One formula covers both wheel and slider.

Caveat: the overlay resize is an async IPC round-trip, so the live window.outerWidth/screenX read can lag a frame during a very fast continuous scroll, causing slight drift. Exact at notch-by-notch speed.

Test plan

• In-window pet: Alt+scroll up/down resizes about the cursor; plain scroll still scrolls the chat; slider still works and agrees.
• Pop the pet out: Alt+scroll resizes toward the cursor, window grows/shrinks to fit (no clipping at any scale).
• Overlay: clicking transparent area around the sprite passes through; clicking the sprite/bubble/mail still works; drag still works.
• Restart with a large popped-out pet → reopens at the right size/spot.