litegraph README still claims 'no runtime dependencies / runs in NodeJS / git subtree'; the ECS branch imports Vue and Pinia into LGraph.ts and LLink.ts

## Summary

`src/lib/litegraph/README.md` still advertises litegraph as a dependency-free, server-runnable, upstreamable subtree. That was already shaky; the ECS migration branch makes it decisively false by wiring Pinia stores and Vue reactivity into litegraph's most core modules.

## The claims

`src/lib/litegraph/README.md`:

```
21: This library is included as a git subtree in the ComfyUI frontend project at `src/lib/litegraph`.
46: - Graphs can be executed in NodeJS
48: - Easy to integrate in any JS application (one single file, no dependencies)
93: It also works server-side using NodeJS although some nodes do not work in server ...
143: Litegraph has no runtime dependencies. The build tooling has been tested on Node.JS 20.18.x
147: This library is embedded via git subtree in ComfyUI_frontend.
```

`CONTRIBUTING.md:267` repeats the subtree framing and links ADR 0001.

## What the branch does to them

Files under `src/lib/litegraph/src/` (production only, `*.test.ts` excluded) importing app-layer modules — merge-base `848cd39ed0` vs ECS ref `333906c4cb`:

| import | merge-base | ECS branch |
| --- | --- | --- |
| `from 'vue'` | 2 | **6** |
| `@/renderer/core/layout/store/layoutStore` | 3 | 7 |
| `@/stores/widgetValueStore` | 4 | 6 |
| `@/stores/linkStore` | 0 | **4** |
| `@/stores/rerouteStore` | 0 | **2** |
| `@/stores/nodeDataStore` | 0 | **2** |
| `@/renderer/core/layout/operations/graphLayoutAttachment` | 0 | **4** |

(File counts via `git grep -l -- 'src/lib/litegraph/src/*'`. Control: `from 'pinia'` is 1 on both refs, so the method distinguishes changed from unchanged.)

The Vue importers by name:

```
merge-base 848cd39ed0: LGraphCanvas.ts, LGraphNode.ts
ECS 333906c4cb: LGraph.ts, LGraphCanvas.ts, LGraphNode.ts,
LLink.ts, node/NodeSlot.ts, node/widgetsView.ts
```

The four new ones are the core graph model, not the canvas renderer. `LGraph` and `LLink` are the two types any external consumer of "one single file, no dependencies" would be reaching for first.

## Why it matters

1. **The upstreaming story is over and nobody has said so.** ADR 0001 chose a git subtree specifically to preserve the option of pushing changes back. A subtree whose `LGraph.ts` and `LLink.ts` import `@/stores/*` and `vue` cannot be pushed anywhere. If that option is being given up, that is an architectural decision and belongs in ADR 0001 (Superseded/Amended) or in the ECS ADR — not left implicit in an import list.
2. **The README is agent-facing.** `src/lib/litegraph/AGENTS.md` is loaded for every session working in that directory. An agent told "litegraph has no runtime dependencies" will write code, or reject code, on that basis.
3. **It is the only place the layering is stated at all.** `eslint.config.ts` does not restrict `src/lib/litegraph/**` — the `files:` glob at 459-465 covers only `src/base/`, `src/platform/`, `src/workbench/` and the deleted `src/world/` (see #15583). So the litegraph → app-layer direction is enforced by nothing except this README's prose, and the prose is wrong.

## Suggested fix

Pick one and write it down:

- **(a)** Accept the coupling. Rewrite `README.md:46,48,93,143` to say litegraph is an in-tree module of the frontend with Vue and Pinia dependencies, mark ADR 0001's subtree rationale as superseded, and drop the "no dependencies / NodeJS" claims.
- **(b)** Keep the boundary. Invert the new edges so litegraph is called by the stores rather than importing them, and add a `src/lib/litegraph/**` zone to `eslint.config.ts` so the README's claim is enforced rather than asserted.

(a) looks like what the branch has actually decided. It just has not been recorded, and the README currently says the opposite.

## Provenance

`git blame` is not usable here (shallow clone), and the GitHub blame API attributes the whole README to `Chore: Oxfmt formatting pass (#8341)` — a reformat that rewrote every line, so blame does not reach the original author. Assigning to @DrJKL as the last toucher of the file *and* the author of the branch that invalidates it, not on a blame result.

Found during a documentation cross-reference sweep of the ECS migration branch. Related: #15583, #15585, #15552.