select: many selected, one active

[zmaril]

Stacked on #122. Last of the Blender-review sequence.

Blender's distinction, and the one that decides what a tool can express: many things are selected, exactly one is active. The selection is what an operation applies across; the active one is what a detail pane shows. With only one of them there's no way to say "these five runs".

pub struct Workspace {
    pub name: String,
    pub layout: Layout,
    /// What is selected, by kind. The last entry is the active one.
    pub selected: BTreeMap<String, Vec<String>>,
}

select grows a mode — replace on a plain click, extend on ctrl/cmd, toggle for the other half — and points unpinned areas at the active one, which is exactly what it did before when every click was a replace.

Two choices that could have gone the other way

Extending onto something already selected promotes it rather than listing it twice — so a count of the selection is right and copying the ids doesn't repeat itself.

Deselecting everything leaves the areas where they were. "Nothing is selected" is not the same statement as "look at nothing", and a detail pane that empties itself when you deselect is a pane that loses your place.

What you see

The runs list draws the distinction — selected rows get a neutral edge, the active one gets the accent — and its copy button becomes "copy 5 selected ids" when there are five. That's the cheapest honest proof that a selection is a thing you can act across.

The file tree takes the same ctrl-click, and now takes its highlight from the host rather than remembering its own last click, so a file picked in one browser is marked in another.

Draw.targets is gone

It was what #109 marked rows from. Selection is the better source: it's what a person chose, rather than what an area happens to be pointed at, and keeping both would be two answers to one question. #109's marking survives — only its input changed.

The thing I'm not deciding for you

Resume-these-five. Run operations aren't on the command bus at all — trigger and resume are daemon calls with their own MCP tools, because Commands take &mut Workspaces and know nothing of host state.

So the payoff multi-select exists for needs the bus to reach host state, and that's a design choice about what the bus is for, not something to slip into this PR. Multi-select makes the question worth answering; I'd rather ask it.

175 tests pass (10 new); fmt clean, clippy clean under -D warnings, docs/reference.md regenerated.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XjCx5QszLXroGYh1YBxybw

[github-actions]

powderman preview

https://powderman-pr-123.fly.dev

The workbench, live: split/join/swap areas, the F3 palette, the widgets, themes, tooltips, the status bar.
The fleet and run execution are inert here (a Fly machine has no herdr) — this is for driving the interface.

On branches with the MCP server, point an agent at it:

claude mcp add --transport http powderman-preview "https://powderman-pr-123.fly.dev/mcp"

Updated on every push. Destroyed when this PR closes.