fix(cli-auth): name minted keys by timestamp, not date

A second login on the same day failed with `A workspace API key named "CLI
(2026-07-30)" already exists` — after the user had already approved in the
browser, so the whole handoff was wasted and there was no way to complete it
without renaming the existing key.

Key names are unique per owner, so the name has to be unique per login. Now
`CLI (2026-07-30 15:42:07Z)`: second precision, UTC so it is unambiguous in a
shared workspace key list and sorts chronologically.

The comment claiming a same-day collision was desirable (so logins would reuse
one key) was wrong — nothing reuses the key, the mint just fails. A collision at
second precision now means something genuinely unexpected, so it is still
surfaced rather than retried under a suffixed name.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EsThUPqZXjwuuyRjBbmVkj

Author: 2 people

apps/sim/app/api/cli/auth/poll/route.test.ts

@@ -99,7 +99,12 @@ describe('POST /api/cli/auth/poll', () => {
       workspaceId: null,
       workspaceBound: false,
     })
-    expect(mockGenerateCopilotApiKey).toHaveBeenCalledWith('user-1', expect.stringMatching(/^CLI /))
+    // Second precision, not day: a date-only name made the second login of the
+    // day fail after the user had already approved in the browser.
+    expect(mockGenerateCopilotApiKey).toHaveBeenCalledWith(
+      'user-1',
+      expect.stringMatching(/^CLI \(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}Z\)$/)
+    )
     expect(mockCompleteApproval).toHaveBeenCalledWith(REQUEST)
     expect(mockReleaseMint).not.toHaveBeenCalled()
   })

apps/sim/app/api/cli/auth/poll/route.ts

@@ -28,18 +28,25 @@ const POLL_RATE_LIMIT: TokenBucketConfig = {
   refillIntervalMs: 60_000,
 }
 
-/** Keys are named for the day they were issued, matching what the CLI prints. */
+/**
+ * Names a minted key for the instant it was issued, e.g. `CLI (2026-07-30
+ * 15:42:07Z)`.
+ *
+ * Second precision, not day: key names are unique per owner, so a date-only
+ * name made the second login of the day fail outright with "a key named …
+ * already exists" — after the user had already approved in the browser. UTC so
+ * the name is unambiguous in a shared workspace list and sorts chronologically.
+ */
 function cliKeyName(): string {
-  return `CLI (${new Date().toISOString().slice(0, 10)})`
+  return `CLI (${new Date().toISOString().slice(0, 19).replace('T', ' ')}Z)`
 }
 
 /**
  * Mints from the key space the approval recorded.
  *
- * A name collision is reported as a conflict rather than retried under a
- * generated name: two logins on the same day from the same terminal should
- * reuse the existing key, and silently accumulating `CLI (date) (2)` rows
- * would hide that.
+ * A name collision is still surfaced rather than retried under a suffixed name:
+ * with second precision it means something genuinely unexpected, and silently
+ * accumulating near-identical rows would hide it.
  */
 async function mintForGrant(
   grant: ApprovalGrant