Debugging: store originating client kind and add unauthenticated `GET` route for looking it up

This is the main scenario we want to handle:
- an extension instance for one IDE variant starts up the sidecar process with a new environment variable (like `IDE_CLIENT_KIND`, etc)
- example: a VS Code instance activates and sets `IDE_CLIENT_KIND=vscode` (from the [built-in URI scheme](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a2293665c880f8b59794bca227db53c8a84c4a7f/types/vscode/index.d.ts#L10693-L10696), same thing the extension uses for [CCloud auth callbacks](https://github.com/confluentinc/vscode/blob/1066a0b2b622b03e4591edca3eebc9afb5a15ea2/src/constants.ts#L10))
- another extension instance for a different IDE variant tries to handshake with the sidecar and fails (receiving 401 responses during the handshake request) due to not having the correct access token
- example: a VS Code Insiders / Cursor instance would either not have the previously-established access token or have a different one from a previous session (since they use different underlying storage than VS Code)

Instead of the current behavior where this other instance tries to restart the sidecar process to establish the correct access token, it would make a `GET` request to this new route and see `vscode` returned in the response body (stored from the originating IDE) which does not match its own URI scheme (`vscode-insiders`/`cursor`/etc) and show a notification to the user that cross-IDE support is not available. (The rest of the UX should be handled extension-side for asking if the user wants to restart the process and use whatever the current IDE is, or something else TBD.)