refactor: migrate runtime client from Orval to ConnectRPC with scoped RuntimeClient

[ericpgreen2]

Migrate the frontend runtime client from Orval + global store to ConnectRPC + scoped RuntimeClient. See tech design for architecture rationale.

Why. The global runtime store prevents supporting multiple simultaneous runtimes, which is needed for cloud editing. Orval generates hooks tied to a singleton HTTP client, so the hooks can't be reused across providers. Since we need new code generation anyway, we migrate the transport to ConnectRPC at the same time — something the team has wanted for a long time.

What changed:

• RuntimeClient class wraps ConnectRPC transport, JWT lifecycle, and service clients. Each RuntimeProvider creates a scoped instance in Svelte context; components read it via useRuntimeClient().
• Custom code generator (scripts/generate-query-hooks.ts) reads ConnectRPC *_connect.ts descriptors and produces TanStack Query hooks with a JSON bridge — consumers keep using Orval-compatible V1* types while proto conversion happens internally.
• All ~330 consumer files migrated from runtime store imports to useRuntimeClient() + v2 hooks.
• Deleted: Orval query/mutation hooks (~10k lines), fetchWrapper, http-client, HttpRequestQueue, StreamingQueryBatch, RuntimeProvider (old), runtime-store.
• Added: ConnectRPC transport with request queue interceptor, RuntimeProvider (v2), RuntimeContextBridge for backward compatibility during migration.

Code samples

Before (Orval + global store):

<script>
  import { runtime } from "@rilldata/web-common/runtime-client/runtime-store";
  import { createRuntimeServiceGetResource } from "@rilldata/web-common/runtime-client";

  $: resource = createRuntimeServiceGetResource($runtime.instanceId, {
    "name.name": name,
    "name.kind": ResourceKind.Alert,
  });
</script>

After (ConnectRPC + scoped client):

<script>
  import { useRuntimeClient } from "@rilldata/web-common/runtime-client/v2";
  import { createRuntimeServiceGetResource } from "@rilldata/web-common/runtime-client";

  const runtimeClient = useRuntimeClient();

  $: resource = createRuntimeServiceGetResource(runtimeClient, {
    name: { name, kind: ResourceKind.Alert },
  });
</script>

Key differences: runtimeClient comes from Svelte context (scoped, not global), the function takes the client object instead of a bare instanceId, request parameters use nested protobuf structure instead of dot-notation, and instanceId is injected automatically by the hook.

Orval type schemas

web-common/src/runtime-client/gen/index.schemas.ts (3,367 lines, ~440 types) is intentionally retained. The v2 hooks use a JSON bridge that accepts these Orval V1* types in their public API and converts to/from proto internally via fromJson()/toJson(). This made the migration tractable — consumers keep their existing type imports unchanged. Migrating to native proto types is future work (see below).

Future work

• Migrate off Orval types. The V1* types in index.schemas.ts are generated from OpenAPI (proto → OpenAPI → TypeScript), losing fidelity on oneof fields and enums. ConnectRPC's protobuf-es generates proper discriminated unions and TypeScript enums. Once this PR lands, we can incrementally replace V1* imports with proto-native types and eventually delete index.schemas.ts and the JSON bridge layer. This would also let us stop running the OpenAPI codegen pipeline entirely.
• Backend ConnectRPC transport. The backend still serves gRPC-Gateway (REST/JSON). Moving to connect-go would let us drop the OpenAPI proxy layer, improving performance and simplifying the stack. The frontend is now ready for this — the ConnectRPC transport supports both JSON and binary proto.
• connect-query upstream integration. Our code generator is custom because @connectrpc/connect-query targets React. If upstream adds Svelte support (connectrpc/connect-query-es#324), we could replace our generator. The hook signatures are designed to be compatible.
• Feature flags per-client. featureFlags is still a module-level singleton. The tech design calls for making it a RuntimeClient property so different runtimes can have different flags.
• Clean up residual instanceId extractions. A handful of files still destructure instanceId from runtimeClient for non-hook uses (query key construction, SSE connections). These are functional but could be tidied.
• Infinite query support in code generator. PartitionsTable was manually converted to use createInfiniteQuery since the generator doesn't emit infinite query variants. Adding this to the generator would cover future pagination use cases.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

---

Developed in collaboration with Claude Code