feat(windows): grid and recursive-grid transition animation

[y3owk1n]

Description

This PR adds the recursive-grid depth transition animation to Windows. Zooming into a cell, or backing out of one, now animates the cells from where the previous depth left them to where the new depth puts them, on the same ease-in-out curve macOS and Linux use and for the duration the config names. A zero duration, or the animation switched off, paints the new depth immediately, and any other draw that takes the surface (a hints frame, grid mode, a clear, a screen change) stops a running transition first.

The frames are paced by a goroutine and each one is handed to the overlay's UI thread through the existing flush path, so nothing on the keyboard hook's thread waits for pixels and frames that pile up coalesce, the same shape the mouse-action indicator already takes on Windows.

The third commit brings the feel of the Linux and Windows zoom up to macOS. The macOS zoom is also a 120Hz timer with a full redraw, so what set it apart was four choices, and both software backends now make them too: interpolated edges land on the nearest pixel instead of truncating towards the origin, a keystroke that interrupts a running zoom continues it on a linear curve instead of easing in again, the virtual pointer rides the zoom from where it was instead of jumping, and each frame reads its progress once it holds the lock.

Plain grid mode has no depth transition on any platform, so the mode coverage table lists transition animation under recursive grid only. The first commit is a prefactor: the easing and origin geometry move out of the Linux cgo backend into a shared untagged package that both backends now use, with no behaviour change on Linux.

Related Issues

Closes #1562

Config

No options added or changed. recursive_grid.animation.enabled and recursive_grid.animation.duration_ms now do on Windows what they do on macOS and Linux, so their platform-support rows read ✅ for Windows and a Windows config that sets them no longer warns at load. Existing configs keep working.

Target Platform

• Platform-agnostic (shared logic, no OS-specific code)
• macOS
• Linux
• Windows

Type of Change

• feat — New feature
• fix — Bug fix
• refactor — Code restructuring (no behavior change)
• perf — Performance improvement
• docs — Documentation only
• test — Adding or updating tests
• chore — Build, CI, dependencies, tooling

Cross-Platform Checklist

• OS-specific files use correct build tags (e.g., //go:build darwin)
• No darwin imports from untagged (shared) code — The One Rule
• Stub implementations added for other platforms (returning CodeNotSupported) — N/A, this replaces a gap rather than adding a port method
• N/A — This PR does not touch platform-specific code

General Checklist

• Code formatted (just fmt)
• just ci passes — N/A, ran the targeted subset instead: just fmt-check, golangci-lint on the touched packages, just lint-cross (the Linux container, which also lints the Windows-tagged files), go vet for windows/amd64 with and without the integration tag, go vet for linux/amd64 CGO off, and go test for config, supportref, architecture and the overlay tree on this host
• Tests added/updated for new or changed functionality
• Documentation updated (if applicable)
• PR title is a conventional commit subject written for users — this PR squash-merges, so the title is what Release Please ships in the changelog, not the commits on the branch

Screenshots / Recordings

None, no Windows desktop on this host. The behaviour is pinned by an integration test that runs on the windows-latest CI leg with a real overlay window: a depth change animates for at least the configured duration and settles on the new cells, a zero duration or a disabled animation paints immediately, and another draw taking the surface stops the transition.

Additional Context

The Linux backend treats a zero duration as its 50ms default; this backend follows the ticket and paints immediately. The manager resizes the window before every recursive-grid draw, so a resize only forgets the last depth when the window's bounds actually changed, otherwise the first zoom would never happen.

[greptile-apps]

Greptile Summary

This PR adds recursive-grid depth-transition animation to the Windows overlay and extracts common easing and geometry calculations for Linux and Windows.

• Drives Windows transition frames from a goroutine while presenting through the existing UI-thread flush path.
• Cancels transition state when another mode, clear, resize, or teardown takes the shared surface.
• Enables the recursive-grid animation configuration on Windows and adds Windows integration coverage.
• Updates cross-platform documentation, although the plain Grid support row currently overstates the implemented scope.

Confidence Score: 4/5

The implementation appears safe to merge, with a non-blocking documentation correction needed for the plain Grid capability row.

The recursive-grid transition is serialized, cancellable, and coalesces complete frames correctly; the only accepted issue is that the support table claims animation for Windows plain-grid rendering even though that path remains immediate.

Files Needing Attention: docs/CROSS_PLATFORM.md

Important Files Changed

Filename	Overview
internal/adapter/overlay/windows/transition.go	Adds a lock-serialized, cancellable frame loop that hands recursive-grid transitions to the Windows UI-thread presentation path.
internal/adapter/overlay/windows/features.go	Detects recursive-grid depth changes, builds transition geometry, and shares the complete-frame painter between animated and immediate draws.
internal/adapter/overlay/windows/overlay.go	Stores recursive-grid transition history and clears it across surface ownership and lifecycle changes.
internal/adapter/overlay/render/motion/motion.go	Extracts platform-neutral easing, rectangle interpolation, and transition-origin calculations without changing reachable Linux behavior.
internal/adapter/overlay/linux/overlay_shared_cgo.go	Replaces local transition arithmetic with the shared motion package.
internal/adapter/overlay/windows/transition_integration_windows_test.go	Covers duration, settling, disabled and zero-duration behavior, and cancellation by a replacing draw on a real Windows overlay.
docs/CROSS_PLATFORM.md	Documents Windows recursive-grid animation support but also incorrectly marks plain Grid transition animation as supported.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Recursive-grid depth changes] --> B[Compute target cells]
    B --> C[Resolve origins from prior frame]
    C --> D[Windows transition goroutine]
    D --> E[Interpolate with shared smoothstep]
    E --> F[Queue complete overlay frame]
    F --> G[Flush to Windows UI thread]
    G --> H[Present newest coalesced frame]
    I[Clear, resize, teardown, or another mode draw] --> J[Cancel or forget transition]
    J --> D

Loading

Prompt To Fix All With AI

### Issue 1
docs/CROSS_PLATFORM.md:949
**Grid support is overstated**

This row now says Windows supports plain-grid transition animation, but the Windows `DrawGrid` path still redraws immediately and clears transition state. Only `DrawRecursiveGrid` gained animation, so this documentation gives users an inaccurate view of plain-grid support.

```suggestion
| **Grid**          | Transition animation           | ✅                         | ✅                         | ❌                          |
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "feat(windows): grid and recursive-grid t..." | Re-trigger Greptile}

[greptile-apps]

Grid support is overstated

This row now says Windows supports plain-grid transition animation, but the Windows DrawGrid path still redraws immediately and clears transition state. Only DrawRecursiveGrid gained animation, so this documentation gives users an inaccurate view of plain-grid support.

Suggested change

	| **Grid** | Transition animation | ✅ | ✅ | ✅ |
	| **Grid** | Transition animation | ✅ | ✅ | ❌ |

Knowledge Base Used: Overlay rendering and presentation

Prompt To Fix With AI

This is a comment left during a code review.
Path: docs/CROSS_PLATFORM.md
Line: 949

Comment:
**Grid support is overstated**

This row now says Windows supports plain-grid transition animation, but the Windows `DrawGrid` path still redraws immediately and clears transition state. Only `DrawRecursiveGrid` gained animation, so this documentation gives users an inaccurate view of plain-grid support.

```suggestion
| **Grid**          | Transition animation           | ✅                         | ✅                         | ❌                          |
```

**Knowledge Base Used:** [Overlay rendering and presentation](https://app.greptile.com/y3owk1n/-/custom-context/knowledge-base/y3owk1n/neru/-/docs/overlay-rendering.md)

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[y3owk1n]

Agreed, and it goes further than Windows: no platform animates plain grid mode, the only depth transition anywhere is recursive grid. The row is removed rather than set to ❌ in 2764816, and the mode coverage table now lists transition animation under recursive grid only.