Support native/public OAuth clients with PKCE without client_secret

[TheDarkSkyXD]

Is your feature request related to a problem? Please describe.

Kick's Authorization Code flow requires PKCE at the authorization endpoint, but the documented token exchange and refresh requests also require client_secret.

Installed applications such as desktop and mobile apps are public OAuth clients: a secret shipped in an application package can be extracted and therefore cannot authenticate the client. The current requirement leaves these applications with three poor options:

• embed and expose the Kick client secret;
• operate a hosted confidential-client relay solely for token exchange and refresh; or
• require every user to create and configure their own Kick developer application.

The hosted-relay option creates an unnecessary cost, abuse, capacity, and availability bottleneck for free/open-source applications as their user bases grow.

This was previously raised in Discussion #36 (converted from issue #23), but it remains unanswered and the current documentation still marks client_secret as required for authorization-code exchange and refresh:
https://docs.kick.com/getting-started/generating-tokens-oauth2-flow

Describe the solution you'd like

Please support an explicit Native/Public client application type using Authorization Code with PKCE (S256).

For registered public clients:

1. The authorization-code token request should accept client_id, code, code_verifier, redirect_uri, and grant_type=authorization_code without requiring client_secret.
2. Refresh should accept client_id, refresh_token, and grant_type=refresh_token without requiring client_secret, with refresh-token rotation/reuse detection as appropriate.
3. Existing confidential web clients should retain their current client-secret requirements.
4. The developer dashboard and documentation should clearly distinguish public/native clients from confidential clients.
5. Loopback redirect URIs for desktop applications should be documented consistently with RFC 8252, including the supported host and port-registration behavior.

This follows the native-app model in RFC 8252 and uses PKCE from RFC 7636 to bind the authorization code to the initiating application instance. The client_id is an identifier, not a secret.

Describe alternatives you've considered

• Embedding or obfuscating the secret: not secure in an Electron, desktop, or mobile package.
• A hosted token relay: protects the secret but imposes recurring infrastructure, rate-limit, abuse, and availability costs on each app maintainer.
• Bring-your-own Kick application: avoids centralized hosting but creates substantial setup friction for ordinary users.
• Device Authorization Grant: would also support installed apps safely, but no such Kick flow is currently documented. It could be an alternative if native Authorization Code + PKCE is not planned.
• Implicit Grant: not requested; Authorization Code + PKCE is the safer modern approach.

Additional context

The request does not ask Kick to weaken confidential-client authentication. It asks for an explicitly registered public-client type whose security model does not depend on a secret that an installed application cannot keep.

Related discussion:
#36