feat(steps): one reply box per outcome

A reply's identity is its status, not its call: a handler answering 200 or 401 draws two boxes (id per function, response, status), so each line from the handler carries its own condition on the picture — the Screens view's idiom — and the anchor's Leads-to list reads as the contract; replies whose status the code does not spell out share one box labelled by the call. Panel note, spec §3.13, CHANGELOG, plan; servers test asserts the ASP.NET and Spring outcomes per box.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01REFyW9hmNrxhwN5wxRoAkC

docs/plans/2026-08-28-steps-and-screens-for-apis-and-web.md

@@ -211,7 +211,7 @@ row, and that the walk reaches the service and the repository call.
 
 *Built* — `src/ui-server/api/effects.ts` (`classifyEffect`, `responseStatus`; rules per language family,
 `process` and Android rows added beyond the plan; `effect.model` / `access`, `site.status`, a response box
-labelled by its codes); tests `__tests__/ui-effects.test.ts`. Matching is on the call as written and on the
+per status since 2026-08-29 — the outcome is the box's identity, the line's pill its condition); tests `__tests__/ui-effects.test.ts`. Matching is on the call as written and on the
 receiver's declared type when the call leaves the index through it — see the status note at the top.
 
 *Where:* `EFFECTS` in `steps.ts` (make it a module of its own, `api/effects.ts`, with a table per