Proxy a request to a sandbox port

The node side of sandbox port previews. People and agents do not call it directly: they open `https://usercontent.b3os.org/sbx/<host_id>/<port>/<token>/<rest>`, and the usercontent Worker checks the token, then forwards the request here (through the tunnel, like the edge) with the token in `x-b3os-port-token`. A path that ends at the token is redirected to the same path plus `/`, so relative URLs resolve under it. beta-api.b3os.org and beta.b3os.org never serve this route (`x-b3os-host: usercontent`). **Port token** (from `POST /v1/sandboxes/{sandbox_id}/ports/{port}/url`, or a public port's `ports[].url`): `pt1.<node>.<exp>.<sig>`. `node` is the signing node's ID (`n1`), `exp` the expiry in Unix seconds (decimal, no leading zeros) and `sig` the base64url (no padding) Ed25519 signature, made with the node key (the one that signs usage batches) over the UTF-8 bytes of ``` "b3os-port-v1\n" + node + "\n" + sandbox_id + "\n" + port + "\n" + exp ``` with `sandbox_id` in `sbx_` form (not the host-safe form) and `port` in decimal. A token is good for that sandbox and port only, until `exp`. The Worker checks the signature with the public key it holds for `node` (`verify_strict`) and the expiry before forwarding; the node checks both again, that `node` is its own ID, that the sandbox is running and that the port is declared, then connects to the port inside the sandbox over vsock. A refused token is `403 signed_url_invalid` with `reason`. **Forwarding.** The proxy forwards exactly seven methods, each declared here as its own operation: `GET` (WebSocket upgrades included), `HEAD`, `POST`, `PUT`, `PATCH`, `DELETE` and `OPTIONS` (`sandboxesProxyPortGet` … `sandboxesProxyPortOptions`). Every other method, `TRACE` and `CONNECT` included, is refused with `405 method_not_allowed` and an `Allow` header naming the seven. The app receives the request at `/<rest>`, without the `/sbx/<host_id>/<port>/<token>` prefix; `rest` may be empty (`…/proxy/` reaches the app's root), and it and the query string are passed byte for byte. The request carries `X-Forwarded-Proto: https`, `X-Forwarded-Host: usercontent.b3os.org` and `X-Forwarded-Prefix: /sbx/<host_id>/<port>/<token>`. The response comes back as the app sends it (status, headers, streamed body) minus hop-by-hop headers, `Set-Cookie`, and the two headers that would reach past the preview's own path on the shared origin, `Service-Worker-Allowed` and `Clear-Site-Data`; `Cookie` is removed from requests too (no cookies on usercontent in either direction). Unless the app sets `Referrer-Policy`, the proxy adds `Referrer-Policy: strict-origin`, so the token in the path is not sent to other sites. A response starts within 65 seconds; a WebSocket or a streamed body stays open up to an hour. **Base path.** All previews share the `usercontent.b3os.org` origin in v0.1 (per-port hostnames are planned): a page served from one port can send same-origin requests to any other usercontent URL it knows, so keep secrets out of previews. Apps should emit relative URLs. Two values describe the base path: - `X-Forwarded-Prefix` (on every forwarded request) is the request's full base path, `/sbx/<host_id>/<port>/<token>`. Build absolute paths from it. - `B3OS_PORT_BASE_PATH` (in the sandbox's environment) is only the fixed start of that path, `/sbx/<host_id>`, the same for every port and URL of the sandbox. It is not a full base path: the port and the token follow it, and the token differs per minted URL, so no value set when the sandbox starts can hold it. A public port's token lasts 7 days from sandbox creation, so its URL and base path (`ports[].url`) stay fixed; a sandbox that runs longer gets a new one.