Return first handshake uriScheme in unauthenticated route

We're getting a lot of "[TypeError: fetch failed](https://confluent.sentry.io/issues/6222581954/events/c167050a87ec46019790c15f2d15ed09/?project=4507583218253824)" alerts from Sentry.

From @shouples:

> the first thing that comes to mind is the sidecar keeping track of the uriScheme that did the first handshake, and maybe we can have an unauthenticated route that returns whatever that value is? for example, if a user starts the extension in VS Code and then jumps over to VS Code Insiders, Insiders will fight to handshake and get 401s (until the sidecar process is killed and the handshake completes)

Start by tracing the sidecar's handshake handling and unauthenticated route behavior described in the issue, including how the first uriScheme is retained. Done means an unauthenticated route returns the uriScheme from the first handshake and addresses the VS Code versus VS Code Insiders 401 conflict.

Written by the indexing model from the issue text.