Feat/wb 682 review node

[dawidaksamski]

What

A second palette item, Review, with its own node type ai-studio/review. It is Human decision with another preset: Approve and Escalate are resume actions, each routed on its own port, and Reject is the one reject action with a required reason. It is the first node to use the several-resume-actions contract.

• Review shares Human decision's template, panel (schema and uischema), output schema and executor. Only defaultPropertiesData differs: the palette item spreads humanDecisionPaletteItem and overrides type, label, description, icon and the preset. The canvas draws one handle per routed action, so a Review node shows three ports with nothing new in the template.
• The author cannot edit the list of actions; that stays a backlog item (follow-up: decision-request-properties-ui).
• Worker: a ReviewNode type joins the AI Studio node union, executeHumanDecision accepts it, and the registry maps ai-studio/review to it. The registry is a mapped type over the union, so the new type cannot be added without its executor.
• Backend: nothing. It finds a decision request by data.properties.decisionRequest, never by node type.
• Icon Scales and the description "Approve, escalate or reject" follow the design spec.

Docs

• AI Studio README: ai-studio/review joins the node type list, with one line on what differs from Human decision.
• Worker README: the decision_request_missing row names both nodes.
• Backend README: the sample review node in "Trying several resume actions on the local stack" had the generic "type": "node" at node level, so AI Studio rendered it with the default template and one handle. It now carries "ai-studio/human-decision", which is how the SDK keys custom templates.

Not in this PR

• The decision form still offers the first resume action, so Escalate is chosen through the API until the next change, which offers every resume action.
• A showcase template with an escalation branch. Left out on purpose; it follows separately.
• Open design points from the spec, each its own decision: outcome names on the canvas rows, the human colour in the palette, a required reason or comment on Escalate, a read-only "Decider actions" section in Properties, and a "leads nowhere" warning for a dangling Escalated port.

Testing

• AI Studio: 602 tests in 44 files pass; tsc, eslint and prettier are clean. New tests pin:
  • the Review preset routes on three handle ids in preset order, all unique, none errorRoute;
  • effects resume, resume, reject, with reject requiring a reason; version 1, empty form, no proposal source or deadline;
  • the palette item is registered exactly once, right after Human decision, under the type the template map uses;
  • it shares Human decision's schema, uischema and output schema by identity, with icon and description pinned;
  • the contract test parses the Review preset with the backend's decisionRequestSchema, beside the two existing requests.
• Worker: 86 tests in 8 files pass; tsc, eslint and prettier are clean. A new case proves a Review node parks the same way. Adding the node type before the registry entry failed tsc on the registry, as intended.
• Manual, on the local stack, a workflow Trigger → Review → two Visualize nodes on the approved and escalated ports, reject unconnected:
  • Decide approve: the approved branch runs, the escalated one is skipped, the run ends completed with no outcome.
  • Decide escalate with a comment: the escalated branch runs, and the comment is in the recorded decision.
  • Decide reject with a reason: both branches are skipped, the run ends with outcome: 'rejected'.
  • A Human decision workflow decided approve behaves as before.
• Manual, in the browser: the Review node draws three handles labelled Approve, Escalate and Reject with the Scales icon, and the palette lists Review after Human decision.