Refuse to boot without R2 credentials

`?? ""` on the access key and secret meant a deployment with no object
storage configured started happily, and `POST /jobs` handed clients
presigned URLs signed with an empty key. The first sign of trouble was a
403 from R2 - either in the client's uploader or, worse, inside a gateway
that had downloaded R2's XML error document in place of a print. Nothing
in that chain said "R2 is not configured".

Reads both credentials through a `required()` that throws, naming the
variable, mirroring auth/verifier.ts and auth/edge_secret.ts.

The endpoint is read with `||` rather than `??`, because the committed
template ships `R2_ENDPOINT=` empty and `??` only catches null - so an
empty value was taken as a real endpoint and the account-id derivation
never ran. That is the trap auth/edge_secret.ts documents, and it caught
this line too, in the first draft of it. A test covers the derivation.

Each boot-failure test fills every other variable so the one under test
is the only thing missing; otherwise whichever variable is read first
wins and the assertion passes for the wrong reason.

e2e-edge.sh gains dummy values, since it boots the backend. It presigns
nothing, so they only have to exist.

.env.example

@@ -11,7 +11,14 @@ DATABASE_POOL_MAX=10
 # understands a `valkey://` scheme.
 VALKEY_URL=redis://localhost:6379
 
-# Cloudflare R2 (S3-compatible)
+# Cloudflare R2 (S3-compatible). The two credentials are required and the
+# process will not start without them: an empty key signs presigned URLs that
+# R2 answers with a 403, which surfaced as a gateway downloading an XML error
+# document in place of a print rather than as "R2 is not configured".
+#
+# Either R2_ENDPOINT or R2_ACCOUNT_ID is needed too - the endpoint is derived
+# from the account id the way Cloudflare's own URLs are formed. R2_BUCKET is
+# not a credential and defaults to "continuum".
 R2_ACCOUNT_ID=
 R2_BUCKET=continuum
 R2_ENDPOINT=