fix: authedFetch URL resolution breaks when DENO_DEPLOY_ENDPOINT contains a path

[uriva]

Problem

When DENO_DEPLOY_ENDPOINT contains a path component (e.g. https://proxy.example.com/deno), the authedFetch function in auth.ts constructs an incorrect URL.

The current code uses:

const url = new URL(endpoint, context.endpoint);

Where endpoint is a relative path like "api/diffsync/org/app/revisionId". The new URL() two-argument form treats the last path segment of the base as a filename and resolves relative to its parent directory. So with base https://proxy.example.com/deno:

new URL("api/diffsync/org/app/rev", "https://proxy.example.com/deno")
→ https://proxy.example.com/api/diffsync/org/app/rev

The /deno path segment is dropped entirely.

Note: The tRPC client in the same file does not have this issue because it uses string concatenation: context.endpoint + "/api".

Fix

Use string concatenation to match the tRPC client pattern:

const url = new URL(`${context.endpoint}/${endpoint}`);

Also added a defensive String() coercion in util.ts's error() function. When authedFetch callers pass an error response body's .message field, it can be undefined if the upstream returns an unexpected response shape — causing .replaceAll() to crash with "Cannot read properties of undefined".

Changes

• auth.ts: Replace new URL(endpoint, context.endpoint) with new URL(\${context.endpoint}/${endpoint}`)`
• util.ts: Wrap error parameter with String(error ?? "Unknown error") before calling .replaceAll()