feat(json-render): expose native rendering for browser contexts

[dvcolomban]

Background (Why)

The reference JSON renderer uses RPC calls and shared state, but its type requires a full hub client context. A browser page with an existing native RPC connection cannot mount it through a public package import. Publishing a JSON view has the same full-context requirement even though it only uses native shared state.

Changes (What)

Expose the existing browser bundle as @devframes/json-render-ui/renderer and view publication as @devframes/json-render/view. Accept their native RPC dependencies directly. Existing custom renderer types still default to the full client context, and the node entry point stays compatible.

Generate the renderer declaration from its existing module. No declaration shim or implementation file moves are needed. Failed initial mounts release their observer and content root. Document that view publishers reuse one context object for discovery and duplicate detection.

This is the JSON-only part split from #410. It adds no transport, authentication or serialization implementation.

Verification (Testing)

Both affected packages build, including the reference renderer and standalone SPA. Focused view, hub renderer, action and renderer tests pass, along with type checks for json-render, json-render-ui and hub. Scoped lint and Knip pass. Thirty API snapshot checks pass against fresh artifacts.

The split RPC and renderer changes were also verified together in a real Chromium extension. All 12 scenarios pass, covering two native connections, rendering, actions, shared-state writes, rich values, failed mount cleanup, disconnect disposal and reconnect. The maintained integration passes in CI. Upstream lint, type checks, Knip, Bun and Deno checks pass; the unit jobs still hit the three baseline diagnostic snapshot mismatches addressed separately in #412.

[vercel]

@dvcolomban is attempting to deploy a commit to the NuxtLabs Team on Vercel.

A member of the Team first needs to authorize it.