fix(service-automation): try_catch Error Variable help describes the caught error in words (#24655)

Fixes #24576

Clause-②: no

The Error Variable help the Studio flow inspector shows for a Try /
Catch node no longer names a TypeScript type. The text is the
`try_catch` descriptor's own `errorVariable` description
(`packages/services/service-automation/src/builtin/try-catch-node.ts`,
`configSchema`); this PR rewrites that one string in words and adds a
patch changeset for `@objectstack/service-automation`.

New text, as served by the descriptor:

> Variable holding the caught error in the catch region (default
`$error`, read as `{{ $error.message }}`). It carries the id of this Try
/ Catch node (`nodeId`), the failure message, which normally names the
step that failed (`message`), the platform error code when that step
reported one (`code`), and, when the failure happened inside a loop, the
zero-based pass number (`iteration`) and the item being processed
(`item`)

## What the engine really binds (measured before writing)

A throwaway probe on the real `AutomationEngine` (probe file deleted,
not committed) ran a `try_catch` whose try region holds one failing step
`push_step`, and printed `$error` from the catch region:

| case | bound value |
| --- | --- |
| step returns a plain failure | `nodeId: guard`, `message: Node
'push_step' failed: boom` |
| step returns a failure carrying `DUPLICATE_RECORD` | the same, plus
`code: DUPLICATE_RECORD` |
| the same inside a loop | plus `iteration: 0`, `item: { id: 'r1' }` |

Two consequences for the wording:

- `nodeId` is the Try / Catch node's own id (`guard`), not the failing
inner step (`push_step`). The inner step is named inside `message`. The
help therefore says "the id of this Try / Catch node" and "the failure
message, which normally names the step that failed", and does not say
"the failing node" as the triage comment words it.
- The old text left out `code`, which the engine has bound for a while;
the new text names it, so an author learns a catch region can branch on
it.

## Verification

- Premise: on `origin/main` `7c7741dcb` line 75 of `try-catch-node.ts`
names the type, as the card says.
- Served text read through `engine.getActionDescriptor('try_catch')`: a
PascalCase identifier scan returns null on the new text and
`TryCatchErrorValue` on the old text (control leg).
- `@objectstack/service-automation`: `tsc --noEmit` plus
`check:test-typecheck` exit 0; full suite 193 files / 2580 tests passed
(run at `f967f573b`, under the shared verify lock).
- Gates: the 59 families `dispatch-gates --commands` derives for this
diff were run; 58 exit 0 and the `--ran` reconciliation reads 59
accounted, 0 unrun. One is NOT MEASURED: `check:dual-build-cjs-loads`
exits 3 (prerequisite not met, it needs every workspace package's
`dist/` and only the service-automation closure was built); CI's `Build
Core` hosts it.

## Acceptance notes

- No test added. Nothing pins the `try_catch` descriptor's help text
(the closest pins, `notify-node.test.ts` and `http-nodes.test.ts`, are
for other nodes); the change is one string and the existing suite stays
green.
- `packages/spec/**` is untouched. The spec's own `errorVariable`
describe still says "The value is a `TryCatchErrorValue`"; the surfaces
that describe reaches are listed in the report comment on #24576 for the
seat to file.
- Not browser-verified: the inspector's help slot was not driven in a
browser. Sibling descriptors (`notify`, `screen`) already carry `{{ }}`
examples in help text.

---
_Generated by [Claude
Code](https://claude.ai/code/session_01LR1cD9JqgkeqY7k9rrZH8s)_

Co-authored-by: Claude <noreply@anthropic.com>

Author: objectstack-fleet[bot]

.changeset/24576-try-catch-help-words.md

@@ -0,0 +1,10 @@
+---
+'@objectstack/service-automation': patch
+---
+
+The flow inspector's Error Variable help for a Try / Catch node describes the caught error in words
+
+Clause-②: no (help text only: the `try_catch` descriptor's `configSchema` accepts exactly what it accepted before, and the value bound to the error variable is unchanged)
+
+- The `errorVariable` description no longer names a TypeScript type (`TryCatchErrorValue`). It now says what the bound value carries, in plain language: the id of the Try / Catch node (`nodeId`), the failure message (`message`), the platform error code when the failing step reported one (`code`), and, for a failure inside a loop, the zero-based pass number (`iteration`) and the item being processed (`item`). The default variable `$error` is named.
+- The old text also left out `code`, which the engine has bound since the classified-code change; an author reading the inspector had no way to learn that a catch region can branch on it.

packages/services/service-automation/src/builtin/try-catch-node.ts

@@ -72,7 +72,7 @@ export function registerTryCatchNode(engine: AutomationEngine, ctx: PluginContex
             description: 'Handler region run when the try region fails',
             properties: { nodes: { type: 'array' }, edges: { type: 'array' } },
           },
-          errorVariable: { type: 'string', description: 'Variable holding the caught error in the catch region — a `TryCatchErrorValue`: `nodeId`, `message`, and `iteration` / `item` when the failure happened inside a loop body' },
+          errorVariable: { type: 'string', description: 'Variable holding the caught error in the catch region (default `$error`, read as `{{ $error.message }}`). It carries the id of this Try / Catch node (`nodeId`), the failure message, which normally names the step that failed (`message`), the platform error code when that step reported one (`code`), and, when the failure happened inside a loop, the zero-based pass number (`iteration`) and the item being processed (`item`)' },
           retry: {
             type: 'object',
             properties: {