The Tree Plot operator can never run: its igraph dependency is Category X

### What happened?

The Tree Plot operator fails at runtime with `No module named 'igraph'` on a fresh
install. Its generated Python template imports igraph (`TreePlotOpDesc.scala:75-76`),
but igraph is not declared in any of the four Python dependency files
(`amber/requirements.txt`, `amber/operator-requirements.txt`,
`amber/dev-requirements.txt`, `amber/pyproject.toml`).

`git grep -il igraph` on main returns exactly one file, `TreePlotOpDesc.scala` itself.
A virtualenv built from the repository's requirements therefore never gets the package,
so the operator can never run unless igraph is installed by hand.

Declaring it is not a way out. igraph is licensed under GPL v2, which is Category X in
the ASF 3rd Party License Policy. I confirmed this from the package metadata on PyPI and
from the LICENSE file inside the installed distribution, and both are GNU GPL version 2.
Adding it to `amber/operator-requirements.txt` makes `bin/licensing/check_binary_deps.py`
fail the build, which is the correct behaviour: the script asks for Category A or B, and
the `licenses/` directory carries no GPL text.

This is the same class of problem as #4084, where rpy2 was separated from releases for
the same reason. That cleanup merged on 2025-12-06. Tree Plot merged earlier, on
2025-07-07 in #3529, so it was already in the tree at the time. It was most likely missed
because igraph was never listed in a requirements file, which means pip-licenses never
reported it and the binary dependency check never saw it.

The remedy taken for rpy2 in #4090 kept the operator descriptors, the registration in
`LogicalOp`, the tests and the worker plumbing in the repository, and moved only the code
that imports the GPL library into an external package. `ExecutorManager` now holds an
`import texera_r` guarded by a try block that points the user at an install command for a
package hosted outside the ASF repository.

Applying that shape to Tree Plot is less direct, because R support already had a natural
seam in the swappable executor class, whereas Tree Plot's igraph usage sits inline in the
Python that `TreePlotOpDesc` generates. The surface is at least small. The operator uses
`Graph.TupleList` to build a graph from parent and child pairs, `graph.vs['name']` for the
node labels, `graph.layout('rt')` for the Reingold-Tilford layout, and `get_edgelist()` to
read the edges back. Only the layout call does real work, and `EdgeSeq` is imported but
never used.

The options I can see are to move the layout computation into an external package as was
done for R, to reimplement the layout on a Category A library such as networkx which is
already a declared dependency, or to retire the operator. There is also a question I
cannot answer myself, which is whether generated source text that names a GPL module
carries the same weight as code that imports it directly, given that nothing in the
repository links against igraph. I am leaving the choice open rather than sending a patch.

### How to reproduce?

1. Create a Python environment from the repository requirements and point
`UDF_PYTHON_PATH` at it.
2. Build a workflow of CSV File Scan into Tree Plot. Any input works, the operator
fails before reading a row.
3. Set Edge List Column to a column holding `[parent, child]` literals and run.
4. The execution fails with `No module named 'igraph'`.

Installing igraph into that environment makes the same workflow succeed, which
confirms the missing declaration is the only cause.

### Version/Branch

1.3.0-incubating-SNAPSHOT (main)

### Commit Hash (Optional)

2c2c0e503

### What browsers are you seeing the problem on?

Chrome

### Relevant log output

```shell
java.lang.Throwable: java.lang.Throwable: No module named 'igraph'
```