fix(auth): use datumctl-cli client_id for device-code grant

Our own OIDC client (datum-desktop-app, configured in
datum-cloud/infra apps/datum-iam-system/.../zitadel-setup/pulumi/index.ts)
has only AUTHORIZATION_CODE + REFRESH_TOKEN in its allow-listed
grantTypes. Zitadel correctly rejects the device-code grant against it:

  unauthorized_client: grant_type "...device_code" not allowed

datumctl-cli (a sibling OIDC app in the same Zitadel project) already
has DEVICE_CODE in its grantTypes and has stable, well-known IDs in
datumctl's source:

  Staging:    325848904128073754
  Production: 328728232771788043

Borrow them for the --no-browser path until the planned datumctl
connect plugin ships with its own properly-scoped client. Tokens are
minted by Zitadel against the same project, so downstream Datum API
calls don't care which client minted them. The audience verifier on
id_token_verifier already allows any audience.

Regular `auth login` (browser flow) is unchanged — it stays on the
datum-desktop-app client.

Author: drewr

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "datum-connect"
-version = "0.2.0"
+version = "0.2.1"
 edition = "2024"
 
 [dependencies]

cli/Cargo.toml

@@ -305,15 +305,32 @@ impl StatelessClient {
         // typestate prevents mutating the cached `self.oidc` in place,
         // and the discovery the constructor performs is cheap enough to
         // accept the duplication.
+        //
+        // HACK: borrow datumctl's OIDC client_id for the device-flow
+        // path. Our own client (the `datum-desktop-app` Zitadel app —
+        // see datum-cloud/infra apps/datum-iam-system/.../zitadel-setup
+        // /pulumi/index.ts) is allow-listed only for AUTHORIZATION_CODE
+        // and REFRESH_TOKEN grants, and Zitadel responds with
+        // `unauthorized_client: grant_type "...device_code" not allowed`
+        // for it. `datumctl-cli` already has DEVICE_CODE in its
+        // grantTypes, so we reuse its client_id strictly for the device
+        // flow until the planned datumctl-connect plugin lands (which
+        // will own its own properly-scoped OIDC client). Token issued
+        // is still scoped to the same Zitadel project; downstream API
+        // calls don't care which client minted it.
         let provider = self.env.auth_provider();
+        let device_client_id = match self.env {
+            ApiEnv::Staging => "325848904128073754",
+            ApiEnv::Production => "328728232771788043",
+        };
         let issuer = IssuerUrl::new(provider.issuer_url.clone())
             .std_context("Invalid OIDC provider issuer URL")?;
         let metadata = CoreProviderMetadata::discover_async(issuer, &self.http)
             .await
             .std_context("Failed to discover OIDC provider metadata")?;
         let oidc = CoreClient::from_provider_metadata(
             metadata,
-            ClientId::new(provider.client_id),
+            ClientId::new(device_client_id.to_string()),
             provider.client_secret.clone().map(ClientSecret::new),
         )
         .set_device_authorization_url(