Spike: guardrail for adding all nodes/edges from the database

> [!IMPORTANT]
> **Internal.** Maintained by the core team; not open to community contribution.

## Goal

Prototype and decide the **guardrail** for "add all nodes and edges from the database" (#2014) — the protection that prevents the feature from running against a very large graph and overwhelming the database or browser.

## Questions to resolve

- **Detection** — how do we know a graph is "too big" before loading? A count query first? Use the schema's total counts? A cheap probe?
- **Threshold** — is there a hard cap, a warn-then-confirm band, and a hard refuse above N? What are the numbers, and are they configurable?
- **UX** — what does the user see: a confirmation dialog with the count, a progress indicator, a "load first N" option, an outright block with an explanation?
- **Partial load** — if the graph exceeds the limit, do we offer to load a bounded subset, and how is that subset chosen?

## Expected outcome

- A recommendation for the guardrail mechanism and UX.
- Tasked-out follow-up so the parent feature (#2014) can be unblocked and built.

> [!IMPORTANT]
> Internal only — this issue is maintained by the core team and is not accepting external contributions.

Start by reading the parent feature in #2014 and reviewing how it would load all nodes and edges. Resolve the detection, thresholds, UX, and partial-load questions, then document a guardrail recommendation and task the follow-up work needed to unblock #2014.

Written by the indexing model from the issue text.