Revert "feat: add pan, zoom, and auto-fit to whiteboard canvas"

[cosarah]

Reverts #31

[cosarah]

Hey @YizukiAme — we're reverting #31 to rework the pan/zoom/auto-fit logic with a different design direction. Here's what we're planning:

1. Preserve whiteboard boundaries: The current implementation turns the whiteboard into a borderless infinite canvas. We want to keep the whiteboard edges visible — zoom and pan should work within a bounded area rather than making it feel unbounded.

2. Move the Reset View button: Instead of a standalone button, we'd like to place it in the top-right corner alongside the existing "clear whiteboard" and "minimize whiteboard" buttons for a cleaner toolbar layout.

3. Always-on drag/pan: Keep the canvas always draggable (no toggle needed), and use cursor states (grab/grabbing) to signal this to the user.

If you have thoughts on the design or want to discuss the approach, feel free to chime in here! Would love your input since you built the original implementation.

[YizukiAme]

@cosarah Thanks for the detailed explanation!! The bounded canvas + always-on drag approach totally makes sense. My original logic of requiring zoom before drag was to prevent accidental panning, but you're right — adding proper boundaries solves that much more cleanly!

I'd be happy to rework the implementation based on these guidelines. A couple of quick thoughts:

Bounded zoom/pan — would you prefer a hard clamp (can't pan beyond edges at all) or a soft resistance (slight elasticity like iOS scroll bounce)?
Reset View button — Good idea! I'll place it alongside the existing top-right toolbar cluster (clear / minimize). The button would be disabled when the canvas hasn't been panned or zoomed, keeping it consistent with the other controls.
I can definitely open a new PR once we align on the details! Should be a quick iteration since the core logic already exists~~

[YizukiAme]

Of course, if the team already has a plan or someone else wants to take this on, totally fine too — happy to help review or contribute in any way! 😊

[cosarah]

@YizukiAme Thank you so much for your contribution and involvement! After discussing with @wyuc, we felt the whiteboard design and interaction needed some refinement, which is why we're reworking this. Your work on #31 was a great starting point and we really appreciate it. Looking forward to your future contributions! 🙏

[wyuc]

While we're reworking the whiteboard, two more things worth considering:

1. Snapshot trigger logic

Right now snapshots are pushed both on clear and on a 2-second debounce after any edit. The debounce path tends to accumulate a lot of intermediate states that users don't really need to restore. Consider only snapshotting before destructive operations (clear / AI clear) since the main use case is "the board got wiped, I want it back."

2. History panel interaction

The current slide-out panel feels disconnected from the history button. A popover/dropdown anchored to the button would feel more natural and match the "click outside to dismiss" behavior users already expect.