protocol/mcp: own the Result to ToolsCallResult adapter - #1718

Fixes fjs/protocol/mcp/todo/result-adapter.md, deleted here.

fjs/protocol/mcp already owns this vocabulary — okResult, and errorResult
derived from it. The missing third member is the one that picks between them,
and five tool handlers had each written that dispatch out by hand:

r => pureOk(r[0] === 'error' ? errorResult(evoSummary(r[1])) : okResult(toJson(r[1])))

toolResultStep(e, text, errorText) is that member. It is resultMapStep over
one fallible operation, rendering the ok value with text and the failure
with errorText into an isError result. Its success channel is
ToolsCallResult and its error channel is never — a tool-level failure is a
result the client reads, never a transport error. Every converted handler is
now one line:

({ subject }) => toolResultStep(e.head(subject), hs => hs.join('\n'), evoSummary)

Two corrections to the issue's design

The issue proposed a pure adapter, resultResult, curried over a single ok
renderer, taking a Result whose error channel is already a string and
answering a ToolsCallResult. Neither half survives contact with the code as it
stands, so the design shipped here differs on both points:

• The error channel is not string. All five sites render a structured
  failure through a summariser (evoSummary in fjs/mcp/evo, errorSummary
  in fjs/mcp/cas), so the adapter takes two renderers, not one. Requiring
  errorText rather than defaulting it is the load-bearing part, for the reason
  unwrapStep gives for its own summary: a renderer written for a particular
  error channel cannot accept a wider one, so a fallible call added upstream
  becomes a compile error at the tool that has to say what the new failure reads
  like, instead of reaching the client as whatever String made of it.
• A pure adapter leaves most of the noise behind. Every call site is
  resultStep(effect, r => pureOk(…)), so an adapter over the plain Result
  would still be spelled r => pureOk(resultResult(…)(r)) at each one. Taking
  the effect makes the handler a single line and is what closes the duplication
  the issue is about. This is not the step(e, x => pure(f(x))) spelling
  map-step-combinator is retiring — it is written with the combinator that
  issue points at, resultMapStep.

The issue also cited a §6.3 that no longer exists under that number after the
guidelines were restructured; the rule it meant is DESIGN.md §4 (DRY) and §9
(signal-to-noise). Nothing else referenced the file, so it is simply deleted.

Scope

The issue's task list named evo_revision and evo_add. evo_list, evo_head
and cas_list are the identical shape and are converted too — five sites, one
improvement. The per-handler comments explaining why a cache-slot failure is a
tool-level error, and why evo_list encodes JSON rather than lines, are kept
where they were.

Checks

• npx tsc — clean.
• fjs test — 3398 pass, 0 fail, including the two new protocol/mcp proofs
  (toolResultStep.okIsRendered, toolResultStep.errorIsRenderedInBand, one
  per branch; the error one asserts isError is set, which is what the never
  error channel claims).
• npm run cov — 100% lines / branches / functions, thresholds enforced.

Changelog:

• protocol/mcp: new toolResultStep(e, text, errorText) — answers a tool call
  with the outcome of one fallible operation, rendering the value or the failure
  (as isError) into a ToolsCallResult.

🤖 Generated with Claude Code

https://claude.ai/code/session_014jZKR1C2qxXCueDSBKBnFg