JS SDK: expose isReady() so consumers can health-check the Lock Server without building a connect URL

[Taewa]

Ask: give the JS SDK an isReady() on Locks.

What a consumer has to do now

A frontend that signs users into the Lock Server wants to check the server is up before it opens the auth flow. That check needs the server's HTTP origin.

The SDK does not expose one.

• lockServer() returns the pubky key, not an origin.
• pkarr resolution happens inside the SDK (resolve_browser_endpoint), and the resolved endpoint never comes back out.
• The only call that leaks it is createConnectUrl, which builds a full URL from the resolved endpoint.

So the caller ends up doing this:

// build a throwaway connect URL just to read its origin
const url = await locks.createConnectUrl(new ConnectUrlOptions(returnTo, crypto.randomUUID()));
const response = await fetch(`${new URL(url).origin}/readyz`);
return response.ok;

Why that hurts

1. One pkarr resolution per check, only to throw the URL away. Starting the real auth then resolves a second URL.
2. A CSRF state is minted for a URL nobody uses.
3. Wrong blame. fetch errors collapse into "not ready", so the only thing left that can throw is the pkarr resolution — a flaky relay is then shown to the user as "Lock Server unavailable" while the server is fine.

Ask

const ready: boolean = await locks.isReady();

SDK resolves the endpoint, calls /readyz, returns the answer. /readyz knowledge stays with the server's own client instead of being re-implemented by every consumer.

Distinguishing "could not resolve" from "server said no" would fix (3) — separate error, or a result the caller can branch on.

An origin getter (resolvedOrigin()) also works and is more general, but then every caller re-implements the /readyz call.