The signed-URL format is the SDK's: write it down and pin the field order

[ursasi]

Related to #90. I did not switch to HMAC, and I think that part of the report
would do harm: the construction is not ours to pick.

What the format is

It is the E2B wire format, on both ends. The official SDK hashes exactly this
string before a URL ever reaches us — packages/js-sdk/src/sandbox/signature.ts
builds path:operation:user:envdAccessToken[:exp] and sends it through
crypto.subtle.digest('SHA-256', …) — and real envd verifies the same digest.
This repo already says so in three places (signing.ts's header,
envd/files.ts:186, and app.test.ts's "the SDK's formula, rewritten rather
than imported"), and the daemon has a test that accepts an SDK-minted
signature. An HMAC on the verification side would reject every URL minted by
the SDK the project exists to be compatible with.

On the length-extension worry: the construction has no graft point, and not by
luck of one field's position — the verifier rebuilds the material from parsed
query params in a fixed order, the token is fourth of five, and the only
component that can follow it parses as a number. There is no place for an
attacker-chosen suffix to survive that reading. What the report rightly flags
is that this reasoning should be written down where the next reader will find
it instead of being re-derived — that is what this PR does.

On "no test would notice" a reordering: several already would (app.test.ts
rewrites the SDK's formula, compat.test.ts and sandbox-proxy.test.ts mint
it, e2e/src/console.test.ts mints it in the browser). I added the missing
one: a signature over a reordered material, and one over a material with an
extra component, both refused.

What changed

• signing.ts and envd-client.ts state that the shape is inherited, name the
  SDK file, and spell out why there is no extension point. Same for the TTL:
  the comment now says the URL is a 15-minute capability with no revocation —
  destroying the sandbox or rotating the API token does not end it.
• btoa(String.fromCharCode(...bytes)) became a loop. This part of the report
  is real: the spread throws RangeError once the buffer grows (I measured
  400 KB). The conversion output is byte-for-byte identical, checked against
  the spread on the same digest.
• New compat test: reordered and extended materials answer 401, canonical order
  still opens the door.

Verification

pnpm vitest run in packages/server: 651 passed, 2 skipped (the Docker
contract suite). tsc --noEmit clean; the console file type-checks too
(target ES2023, so the loop is fine). biome check reports the same 10
pre-existing noUnsafeOptionalChaining findings in compat.test.ts as before
the change.

If you do want a signature scheme of our own on top of the SDK-compatible one,
I am happy to work on that as a separate design — but it has to be a second
URL form, not a change to this one.