Support multiple scratchpads per workspace

[frostmark]

Problem

A workspace currently has exactly one scratchpad. The tab id is a fixed singleton (scratchpad in lib/workspace-tabs.ts, alongside agent and widgets), and the canvas state lives in a single .moi/.scratchpad.json per project.

This works well for a single ongoing discussion, but breaks down once the workspace hosts more than one stream of work. Examples:

• Sketching an architecture diagram while also keeping a separate planning/brainstorm board — both end up interleaved on one infinite canvas.
• Working with an agent on two unrelated tasks (or in two chats, which already share one workspace): their sketches collide, and moi scratch clear wipes everything, not just the finished topic.
• Long-lived reference diagrams get mixed with throwaway sketches, so there's no cheap way to "start fresh" without losing the board you want to keep.

Views already solve this for apps — each view gets its own tab (view:<id>). Scratchpads have no equivalent.

Proposed solution

Allow multiple named scratchpads, each in its own tab, following the pattern views already use:

• Tab ids like scratchpad:<id> (keeping bare scratchpad as the default one for backward compatibility).
• Per-canvas state files, e.g. .moi/.scratchpad/<id>.json.
• moi scratch commands take an optional --pad <id> (defaulting to the default pad), so existing agent workflows keep working unchanged.
• Some way to create/rename/delete pads from both the UI and the CLI (moi scratch pad new/list/delete or similar).

Alternatives considered

• Embedding tldraw inside a custom view gives a second canvas, but loses everything moi scratch provides (agent read/draw primitives, view/read-image, live sync).
• Sectioning one infinite canvas by convention ("top-left is for planning") — fragile, and clear is still all-or-nothing.