[nicoloboschi]

Fixes #5703.

Problem

On a bank with a few thousand observations, the Memories → Constellation view (and "Load more") made GET /banks/{id}/graph freeze the event loop for seconds. /health/live could not answer, and Kubernetes restarted the pod, failing recall/retain for every client.

Only the stored links were capped (10k). The edges the engine derives on top of them (observations inheriting their source memories' links, observations sharing a source, memories sharing an entity) had no cap. A dense bank derived hundreds of thousands, then validated them against the response model, all on the loop.

Fix

• Cap the derived edges (GRAPH_MAX_EDGES, now shared by the store and the engine). Stored links (with the ones observations inherit) and derived edges each get a 10k budget, so a well-linked bank still shows entity edges. Derivation stops at the cap, shared source before shared entity (rarest entity first, since a name in every memory says nothing).
• Build in a worker thread, after the DB connection goes back to the pool.
• Encode with orjson instead of validating thousands of nodes against GraphDataResponse on the loop. The OpenAPI schema is unchanged; tests/test_graph_assembly.py holds the built dict to the model's shape.

No node limit: the Table view uses the same endpoint, and its "Load more" grows limit instead of paging, so capping nodes would break it.

Behaviour changes

• Graphs that would have derived more than 10k edges now show at most 10k stored + 10k derived, picked in the order above. Smaller graphs get the same edges as before.

Evidence

Synthetic bank (store mocked, machine heavily loaded, so times are inflated):

nodes	before	after
1,000	205k edges, 61 MB, 72s loop stall	10k edges, 4.3 MB
7,000	did not finish	10k edges, 13 MB, encoding ~20 ms (validation was ~10 s)

23 graph-related tests pass (new test_graph_assembly.py, plus graph filtering, tag scope, row models, cancellation, HTTP integration).