Ambient "operator recommender"

### Feature Summary

Building a workflow today requires knowing the operator catalog well enough to pick the next operator by name. The existing chatbot helps, but only **on demand** — the user has to stop and ask. There is no ambient guidance at the moment of authoring.

This proposes an **ambient operator recommender**: after an operator is added to the canvas, 1–3 faded suggested operators appear on its output port showing the most likely next operators. Clicking one materializes it and wires the link. It behaves like code completion, but for dataflow graphs — predictive and non-intrusive, never blocking the user.

Design was discussed and agreed in #5240.

| | Existing chatbot | Operator recommender |
| --- | --- | --- |
| Trigger | User asks | Operator added to canvas |
| Mode | Conversational | Ambient, ranked suggestions |
| Cost | LLM call per turn | Zero in V1; small model in V2 |

### Proposed Solution or Design

Ship in two versions, as agreed in #5240 (zuozhiw: "the plan sounds good, please go ahead with first steps"; xuang7: V1 needs no LLM call, "default configuration should be sufficient").

**V1 — hardcoded, zero API cost.** Validates the whole pipeline before spending anything on inference.

```
canvas: operator added
│ getOperatorAddStream()
▼
frontend hook ──POST /api/recommend──► agent-service (stateless)
◄──── ranked suggestions ───── hardcoded rule table
│ + operator catalog validation
▼
1–3 suggested operators on output port ──click──► materialize + link
```

- `POST /api/recommend` in `agent-service`: stateless, no DB, no LLM, no user token.
- Ranks from a small hardcoded successor table keyed on the real operator catalog.
- Suggestions validated against the live catalog (`WorkflowSystemMetadata`), so a stale rule degrades to "not suggested" rather than a broken suggestion.
- Response carries a `strategy` discriminator (`"hardcoded"` / `"llm"`) so V2 swaps in behind the same request/response shape, no breaking change.
- Frontend suggestion rendering gated behind a new opt-in GUI config flag, default off.

**V2 — LLM-backed ranking.** After community feedback on V1.

- Replace the rule table with a small, cheap, openly-available model via the existing LiteLLM gateway (custom model training ruled out as infeasible in #5240).
- In-memory caching with auto-eviction; still stateless, still no DB.
- Add repo-versioned operator descriptions, example workflow patterns, and a ranking test set, plus a CI evaluation of ranking quality.

**Scope of this issue** is V1 only, split into two PRs:

| PR | Scope |
| --- | --- |
| 1 | `agent-service`: stateless `POST /api/recommend`, hardcoded ranking, catalog validation, unit + route tests |
| 2 | `frontend`: subscribe to operator-added events, suggestion rendering on output port, click-to-materialize, opt-in config flag |

V2 will be tracked as a follow-up issue.

### Affected Area

Workflow UI, Other