feat(mcp): split the library and automation surfaces read from write

[cpellan561]

organize switched behaviour on which arguments arrived: no short_ids read the
workspace vocabulary, short_ids alone inspected artifacts, and
add/remove/set/collection/state wrote, including state:'deleted', a permanent
delete. A tool containing that has to declare destructiveHint, so browsing a tag
vocabulary prompted the user exactly as hard as destroying an artifact. automate
had the same shape, with list sitting alongside create/run_now/record.

tool	annotation	does
browse_library	readOnly	the reads
organize	write	tags + collections, honestly non-destructive
shelve	destructive	retire / restore / delete, the one hard verb
list_automations	readOnly	the read
automate	write	create / run_now / record / create_context

Annotation-honouring clients auto-approve read-only tools, so the common path stops
interrupting. That is the reason to do this. MCP directory review happens to require
the same split, which is how it surfaced.

Behaviour is unchanged for everything already reachable

Each pair is one handler with two or three schemas over it. The handler still
routes on which arguments arrived, so every guard, cascade and response shape is the
code that was already there. Worth knowing before you open the diff: most of it is
reindentation from extracting that handler, not new logic.

The one deliberate behaviour change: automate now refuses action:"list"
rather than merely not advertising it. Easet it allows, so
the split is enforced server-side. A split that exists only in a description is not a
split: a caller with a cached schema woule read through the
tool that declares itself a write. This is the line to argue with if you disagree,
since anything passing that string breaksing the read.

Two things deliberately preserved

• **shelve keeps both directions on oneoriginal comment
  argues that splitting retire from restore "is how you end up with a surface that can
  retire something and no obvious way bac response still
  hands back its own undo, now naming shelve.
• **list_automations keeps the owner gation branch, so
  listing automations always required owner. Splitting a surface is not the moment to
  quietly widen a permission, even thoughmpting.

The design rule in mcp.ts needed amend

"A new capability is a parameter on an exl" still holds, and
now carries one stated carve-out: a parameter may not take a tool across the read/write
line, because annotations are per-tool anthout that, the next
reader follows a rule the code no longer fully obeys. That header also claimed TEN tools
while serving twelve, before this change.

Budget

SURFACE_BUDGET 11000 to 11450 (tool deseasured 3571 + 7636
= 11207. That is +532 characters for three more tools, roughly 130 tokens against a
surface already costing ~2.6k, and the paplicated
workspace / short_ids text without moving.

The rationale sits at SURFACE_BUDGET, the number the file itself says is the one that
matters, rather than being duplicated acrd as what it is: the
first raise that buys something, fewer approval prompts and annotations that are true,
rather than paying for a new capability.

Verification

pnpm run ci clean, pnpm typecheck clesing. Both failures
are the 5000ms coverage-load flake; all 191 tests in those two files pass in isolation.

wanted("organize") now gates all three library tools and wanted("automate") both
automation tools, so a caller naming either still gets a coherent set.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

Preview

https://derive-pr-705.derive-to.workers.dev

Deployed from ccbd72f as derive-pr-705.

It shares production's database — sign in with your real account, and treat anything you change here as changed for real. It has no routes, no cron, no queue consumer and no OG renderer, so it cannot serve derive.to, run scheduled work, or write images onto real artifacts.

Unlike production it serves artifact HTML on its own origin (that is what makes frame-side changes visible here). Storage is still sandboxed away, but untrusted HTML and the sign-in form share a hostname — treat this URL as you would any link: don't type a password into it because a page asked you to.