feat: tiling-WM-style pinned relative placement for canvas tiles

[srid]

Kolu's canvas today lets you freely place tiles, but there's a recurring UX need for "put this tile next to that other tile, and move it when the other tile moves/resizes/is replaced in focus." Most concrete cases:

• A browser tile that should live next to the terminal whose dev server it's previewing — see feat: embeddable web browser as a canvas tile (phases 0–2) #633 (this issue is why feat: embeddable web browser as a canvas tile (phases 0–2) #633 intentionally defers placement behaviors here).
• A log-tailing terminal that should sit below the app it's watching.
• Any "paired tiles" workflow during a recording or demo.

Doing this as a per-feature structural binding (e.g. browser-is-a-sub-panel-of-terminal) complects the paired tiles and fights canvas identity. Doing it as a general canvas capability keeps every tile a peer and makes the behavior reusable across terminal, browser, and any future tile type.

Proposal — pinned relative placement

• A tile can be "pinned" relative to another tile with a direction (right / left / above / below) and a size ratio.
• When the anchor tile moves, resizes, or gains focus (e.g. maximize), the pinned tile follows.
• Unpin at any time — the tile reverts to free canvas placement.
• Pin operations live on the canvas layer, not inside any specific tile's state. Tile types don't need to know about pinning.

Tiling-WM-inspired extensions (post-MVP)

• Snap-to-grid / snap-to-edges with magnet affordance.
• Master/stack layout preset (one big tile + column of small ones).
• Keyboard shortcuts to cycle pin direction (Mod+Shift+L = pin right of active, etc.).
• Pin groups: a set of tiles that move together.

Non-goals initially

• Tabbed/stacked layouts (Kolu already has a chrome pill tree for navigation).
• Full i3/Sway compatibility.
• Programmatic pin via config file.

Motivating consumer

#633 (browser canvas tile) will be the first adopter. That issue intentionally ships without any placement behavior beyond "free canvas tile," trusting this feature to land generically rather than building a one-off binding between browser tiles and terminals.

[srid]

Design rationale

This issue exists because #633 (browser canvas tile) needed placement behavior ("browser tile sits next to the terminal whose dev server it's previewing") and we explicitly refused to build it as a per-feature binding on the browser tile. Recording the reasoning here so the separation holds.

Why this is a canvas-level feature, not a per-consumer one

The user's original instinct for #633 was "right split per terminal," modeled like the existing down-split for child terminals. Rejected because it would have:

• Bound browser lifetime to terminal lifetime (Lowy: wrong volatility axis — placement is the most volatile thing in the design; identity and lifecycle are stabler).
• Overloaded SubPanelState in packages/client/src/terminal/useSubPanel.ts:8-31 with a second variant kind (Hickey: parallel-optionals encoding a sum type).
• Created a bespoke "browser lives inside a terminal" coupling that no future tile type (logs viewer, chart, preview grid) could reuse.

Instead: placement is a property of the canvas, applicable to any pair of tiles. Browser tile (#633) is the first consumer; terminal-below-app, chart-pinned-to-table, and any future "paired tiles" pattern get it for free.

Why pinning and not a layout manager (i3/Sway)

Considered but deferred:

• Full tiling WM semantics (master/stack, binary tree, workspace rules): too much mechanism for the handful of use cases Kolu actually has. Ship the primitive (pin A to B with direction + ratio) and grow from observed usage.
• Tabbed/stacked layouts: Kolu already has the chrome pill tree for navigation; a second tab system would fragment the mental model.
• Config-file programmatic pinning: premature until the UX pattern has stabilized.

What the MVP of this should and should not include

Include:

• Pin direction (right/left/above/below) + size ratio.
• Follow-behavior on anchor move, resize, and focus change.
• One-click unpin.
• Canvas-level storage (not tile-level) so tile implementations don't learn about pinning.

Exclude (explicitly, for the first cut):

• Keyboard-driven pin cycling (nice later).
• Pin groups / pin chains.
• Snap-to-edges with magnet affordance.
• Auto-pinning policies ("when a new browser tile opens from a terminal's URL suggestion, auto-pin it right"). That's a feat: embeddable web browser as a canvas tile (phases 0–2) #633 Phase 3-ish consumer policy, not a primitive.

Relationship to #633

#633 ships zero placement behavior. Browser tiles are free canvas tiles. When this issue ships, the "browser preview next to its source terminal" UX becomes a composition: open a browser tile from a URL suggestion in #633, pin it to the terminal via the generic pin UI introduced here. No code in #633 needs to change to enable it.

That composition is the whole point of keeping them separate.