perf: memoize URL and route resolution in link codecs - #1951

ℹ️ No critical issues — one minor suggestion inline.

This PR is stacked on #1950; I reviewed only the last two commits (41e3985 perf change and f2a3e54 bench fold). The memoization is well-engineered and well-tested: the WeakMap identity cache in pathToHttpPath, the single-slot base-url parse caches, and the OpenAPILinkCodec route memoization (with in-flight dedupe via routePromises cleared in finally, so failed resolves are retried) are all correct. The dotted-vs-nested cache-key test genuinely pins the stringifyJSON keying, and the lazy-load tests meaningfully exercise the dedupe/not-cached semantics. I ran the affected suites (191 tests) — all pass. The untraced StandardLink fast path preserves behavior: without a configured tracer neither the outer span nor the three inner runWithSpan wrappers were ever observable, so skipping them changes nothing but cost. The one item worth flagging is the interceptors snapshot in createORPCClient, inlined below.

Reviewed changes

• Added a module-level WeakMap identity cache to pathToHttpPath so memoized path arrays skip re-encoding.
• Added single-slot base-URL parse caches to the RPC and OpenAPI link codecs, keyed by the resolved URL value.
• Memoized OpenAPILinkCodec route resolution (meta, method, structures, merged pathname, dynamic params), shared between encodeInput and decodeResponse, resolving once instead of twice with in-flight dedupe and no caching of failed lazy loads.
• Added an untraced fast path to StandardLink.call that skips span-name construction and the runWithSpan wrappers when no tracer is configured.
• Hoisted the client interceptors array out of the per-call closure in createClient.
• Folded codec depth/params/query scenarios into the existing bench files.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

ℹ️ Re-review of the new commit (73fc524 "fix: preserve cache and promise semantics") — no new issues found.

This run re-reviews 73fc524, which sits on top of the previously-reviewed 41e3985 + f2a3e54. It hardens the memoization from the first review, and each fix is genuinely pinned by a test that fails without the change. I verified the affected suites — http.test.ts, openapi-link-codec.test.ts, and link.test.ts — 144 tests pass. The prior minor thread on the client.ts interceptors snapshot (a requested inline note) is unchanged by this commit and stays open below the approval gate; it is non-blocking.

Reviewed changes

• Changed pathToHttpPath to store [path.slice(), httpPath] in its WeakMap and validate on every hit (length + .every(===)), so reusing a mutated array can no longer return a stale encoded path. The new mutation-invalidation test locks this in.
• Wrapped the untraced StandardLink.call interceptor invocation in Promise.resolve/Promise.reject so a synchronously-throwing interceptor yields a rejected promise instead of a synchronous throw, matching the traced path and the Promise return type. New test asserts the promise rejects with the thrown error.
• Deferred OpenAPILinkCodec.computeRoute behind Promise.resolve().then(...) and snapshotted the path, so a synchronously-throwing lazy loader self-cleans from routePromises in finally (never cached) and an in-flight lazy path array mutated mid-load cannot corrupt resolution. Two tests pin the not-cached (loads === 2) and stable-path behaviors.

ℹ️ Nitpicks

• pathToHttpPath now pays O(depth) for the length check + .every on every cache hit — the previously O(1) fast path this PR optimizes. The trade-off is fair (still far cheaper than encodeURIComponent + join), but since this is a perf PR it's worth re-running the depth benchmarks after this commit to confirm the memoized-array hot path didn't regress materially; trusting the documented stable-array contract is an alternative if it did.

# Snapshot-validation cost on pathToHttpPath

## Affected sites
- packages/shared/src/http.ts:12-18 — per-hit length + `.every(===)` scan.

## Required outcome
- Confirm the added O(depth) snapshot check does not materially regress the memoized-array hot path measured in `benches/rpc-link-handler.bench.ts` / `openapi-link-handler.bench.ts`. If it does, prefer trusting the documented stable-array contract (mutation-miss) over validating every hit.

## Open questions for the human
- Is in-place mutation of a shared client path array a real scenario, or is the mutation guard theoretical? If theoretical, the snapshot may not be worth its per-hit cost.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}