Resolve APP_URL before the checkout try, and move to SDK rc.9

[Evy04]

The bug

appUrl() was called inside the try/catch around createCheckout:

try {
  const { url } = await rekey().billing.createCheckout(session.accessToken, {
    successUrl: `${appUrl()}/library?bought=${slug}`,   // throws in here
    ...

So a missing APP_URL was caught alongside declined cards and archived plans,
and rendered to the buyer as "Could not start checkout". An operator's
misconfiguration reported as a payment failure, with the one sentence naming
the real cause swallowed on the way out.

This is not hypothetical: the same bug on nextjs-starter cost an afternoon.
Checkout looked broken end to end when one variable was blank.

The fix

Configuration is resolved before the try, so it escapes as a real error. The
catch still covers genuine checkout failures, which correctly surface the API's
own message.

The helper moves to lib/app-url.ts to match the starter. It stays a throw
rather than becoming a boot-time check because next build runs on machines
with no environment at all, which is most CI: failing at import would break the
build rather than the request that actually needs the value. lib/rekey.ts is
lazy for the same reason.

Also

@rekey.dev/* from rc.6 to rc.9. That carries the restyled drop-in
components and the RekeyProvider fix where any failed /auth/me refetch
signed the user out.

Verification

tsc --noEmit clean; npm run build clean; the built server booted and
/, /p/grid-icons and /sign-in all return 200 with the expected content. A
green build alone was not treated as evidence.