Make operators easier to find and understand in the workflow editor

Start by locating the workflow editor's palette search, canvas operator rendering, graph connection handling, and selection flow; no file paths or tests are identified in the issue. Separate the three proposals into independently reviewable work, then verify keyword search, hover context, and suggestion placement and wiring against existing UI behavior before treating each part as done.

Feature Summary

Texera ships 166 operators across 26 groups, and there are three moments where
the editor gives a user less help than the metadata it already has could:

1. Finding an operator. The palette search matches the query against
   userFriendlyName only. A query phrased as an intent — "remove repeated
   rows" — matches no name, so it returns nothing, even though Distinct's own
   description says exactly that. Every operator carries an
   operatorDescription; the search never reads it. In practice the search only
   helps someone who already knows the operator's name.

2. Reading a workflow. Once an operator is on the canvas it shows a name and
   nothing else, and a renamed one does not even show that. Understanding
   someone else's workflow means clicking each operator to open its properties.

3. Knowing what comes next. With a workflow half-built, there is no hint of
   what usually follows the selected operator; the user goes back to the search.

Proposed Solution or Design

Three independent, frontend-only changes, each as its own PR so they can be
reviewed and accepted separately. None touches the backend.

A. Context on hover. Hovering an operator on the canvas shows its group and
description plus its neighbours in the current workflow (what feeds it and what
it feeds). The description is existing metadata; the connections are read from
the workflow graph, so nothing is inferred. The card follows graph changes while
open. It stays out of the way while the heat-map overlay owns the hover.

B. Semantic operator search. The palette search also ranks operators by
meaning, in the same box, with no mode to choose. Keyword matches still render
first and instantly, so typing a name behaves exactly as today; ranked matches
fill in underneath. Operator vectors are computed offline and committed as a
~490 KB asset; at runtime only the query is embedded, in the browser, with
all-MiniLM-L6-v2 through Transformers.js. No backend, no API key.

Measured on 166 queries — one per operator, written from the operator catalogue
without seeing the index — the current search returns the expected operator in
the top three for 2 of them; the combined search does for 137.

C. Next-operator suggestions. Selecting an operator shows what usually
follows it; choosing a suggestion places it next to the selected operator and
wires the two. Suggestions come from a small rule table keyed by operator group,
ordered by the links in Texera's own example workflows.

This came out of the UP Hackathon (September 2026), where these were presented
to Chen Li. We would like to confirm the direction before the PRs are
reviewed, and are especially interested in feedback on B's runtime model
download (see the PR for the options).

Affected Area

Workflow UI