perf: lazy-load stdlib; defer stage registration until referenced by a graph

[alpibrupa]

Problem

load_stdlib() eagerly loads ~46 stages into memory at CLI startup, regardless of whether the graph being run references any of them. This costs:

• Cold-start latency (agent-facing; every noether run pays the full load).
• Memory footprint (in ephemeral containers, small but real).
• Embedding index construction time (semantic index must cover every stage loaded).

Proposed fix

1. Parse the target graph first (crates/noether-engine/src/lagrange/ast.rs) and collect the set of signature_ids it references (transitively through Let/Branch).
2. Load only those stages from the store (local or remote). Stdlib becomes just another lazy-resolved registry.
3. Keep a --preload-stdlib flag on noether run for workflows that intentionally want the full catalogue in memory (introspection, bench).
4. Measure: log cold-start p50 and memory before/after on a minimal 3-stage graph.

Acceptance criteria

• noether run simple-graph.json loads only stages referenced (+ transitive deps).
• noether stage list still shows the full stdlib (unaffected).
• Benchmarks recorded in docs/engineering/perf/ showing cold-start improvement.

Priority

Low — polish; real impact is ~10% cold-start improvement for ephemeral invocations. Worth picking up once higher-priority issues clear.

[alpibrupa]

Profiled load_stdlib() on main (release build, 80 stages):

• first call: ~9.9 ms
• warm median: ~5.2 ms

Debug build: ~51 ms cold / ~34 ms warm (not the shipping mode).

The stdlib is a pure-Rust Vec — no disk or network I/O. Cost is just constructing 80 Stage structs, SHA-256 hashing signatures, and Ed25519 signing with a deterministic key.

At ~10 ms cold in release, lazy-loading saves at most a handful of ms on noether run cold-start. The refactor cost (introducing graph-first parse, signature_id collection, transitive closure over stdlib deps, keeping stage list intact via a second eager path, --preload-stdlib flag) is substantially larger than the payoff.

Suggest closing as won't-fix, or keeping open as a very-low-priority if someone later shows a measurable win on a real workload. Happy to revisit if the stdlib grows 10x.