To support users in languages that do not have existing UCAN invocation implementations, we are going to launch a bridge that allows them to make simple HTTP requests with JSON bodies that we transform into proper UCAN invocations.

So far this PR has:

1) an untested (but type-checking!) implementation of such a bridge
2) a markdown description of the bridge protocol, intended to be the first draft of an eventual specification

Notable design choices:

1) I chose to include JUST the base64pad-encoded "secret" in the Authorization header to avoid running afoul of maximum header size restrictions that exist in [some HTTP environments](https://stackoverflow.com/questions/686217/maximum-on-http-header-values).
2) The `proof` field of the JSON body is a base64pad encoded "delegation archive" (created with `ucanto`'s `Delegation.archive` function)

TODO
- [ ] factor core bridge logic out to a separate library
- [ ] factor HTTP input wrangling out to a separate function
- [ ] rename `UPLOAD_API_DID` and `ACCESS_SERVICE_URL` environment variables to `W3UP_SERVICE_DID` and `W3UP_SERVICE_URL`
- [ ] add tests
- [ ] expand and formalize bridge specification, move it to the specs repo (?)

update spec to use https:// github.com/ucan-wg/ucan-http-bearer-token?tab=readme-ov-file#ucan-as-bearer-token-specification-v030 and move the secret to a new `X-Auth-Secret` header

update implementation per this spec - currently typechecks cleanly but throws an error when I actually try to invoke:

```
TypeError: proof.export is not a function or its return value is not iterable
    at delegate (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/core/src/delegation.js:466:33)
    at IssuedInvocation.buildIPLDView (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/core/src/invocation.js:101:12)
    at writeInvocations (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/core/src/message.js:114:35)
    at MessageBuilder.buildIPLDView (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/core/src/message.js:79:52)
    at Object.build (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/core/src/message.js:30:49)
    at execute (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/client/src/connection.js:48:31)
    at Connection.execute (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/client/src/connection.js:35:12)
    at IssuedInvocation.execute (/Users/travis/dev/pl/w3infra/node_modules/@ucanto/core/src/invocation.js:115:39)
    at handlerFn (/Users/travis/dev/pl/w3infra/upload-api/functions/bridge.js:124:38)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
```

I think this is because the `@ipld/dag-ucan` `Ucan.View` is not a full `Delegation`

worked with @gobengo and @Gozala to refine the design on this bridge - this is roughly the latest thinking, missing just a few things from PR reviews

1) add content negotiation and support CBOR
2) better parsing abstractions
3) validate tasks before casting

one slightly weird thing I'm doing is converting the string I get from the AWS lambda to a ReadableStream and then reading it back again - seems silly in this implementation, but is necessary because I plan to pull out the abstraction and support other deployment environments like Cloudflare workers or Node's `fetch` API.

also error on unsupported content type

need to update spec

look up required env variables at deploy time

had to upgrade w3up-client to bring in the coupon functionality

1) default to reading the request body as dag-json
2) use `p` and `s` instead of `data` and `sig`, to match https://github.com/ucan-wg/invocation/blob/c596f04bbaf56c58df76bb578c6dfd53bb88bece/README.md#receipt-response
3) use `dagJSON.decode`

The bridge was configured to point at staging even when it was running in a PR environment, because we don't customize the `ACCESS_SERVICE_URL` in those environments.

It would be nice to figure out how to set the proper environment variables in different environments, but I suspect the right way to do that might change with the SST upgrade, so for now let's just add a function that encodes the rules we know, since these aren't likely to change soon and would require some code changes anyway.

hooray!