perf(utils): guard useStreamJSON lifecycle

[JustYannicc]

What changed

• Added a mounted/latest-run guard to useStreamJSON so stale fetches cannot write data, error, isLoading, or invoke callbacks after a newer run starts.
• Added lifecycle abort cleanup for active requests on revalidation and unmount.
• Composed the hook-owned abort signal with any caller-provided RequestInit.signal without aborting the caller-owned signal.
• Added a focused scripts/test-use-stream-json-lifecycle.mjs hook harness.

Why

useStreamJSON could start an initial request and then another request via revalidate(). If the older request settled later, it could overwrite the newer result or fire stale onData / onError callbacks. It could also settle after unmount and attempt state updates.

Compatibility impact

The public return shape and options are preserved. Existing caller signal values are still observed by the fetch request; lifecycle cancellation now uses a composed signal so SuperCmd can abort stale work without mutating caller-owned controllers.

How tested

• Before evidence: node --test scripts/test-use-stream-json-lifecycle.mjs failed before the hook change, showing stale data overwriting latest data, stale errors surfacing, missing unmount abort cleanup, and missing lifecycle signal composition.
• After: node --test scripts/test-use-stream-json-lifecycle.mjs passes.
• LSP: use-stream-json.ts reports no TypeScript diagnostics.
• git diff --check HEAD~1..HEAD passes.
• ./node_modules/.bin/tsc -p tsconfig.renderer.json --noEmit --pretty false is blocked on the clean origin/main base by existing unrelated renderer errors outside this patch.

Stack validation

This PR branch was created from origin/main and cherry-picked only the scoped fix from codex/perf-stream-json-lifecycle, so it does not include or depend on the performance integration stack.

[JustYannicc]

Superseded by #555, which now includes the scoped useStreamJSON lifecycle fix, focused harness, and updated performance/test evidence.