fix: treat already-handled device authorization as success

[mattdjenkinson]

Summary

Running datumctl login --no-browser succeeds, but the browser still shows a red error: Device Authorization Request has already been handled (COMMAND-D30Jf). The login works, so the error is confusing and looks like a failure.

The cause is that the /signedin page completes the device flow inside a Server Component render by calling completeDeviceAuthorization. The App Router does not guarantee a render runs exactly once per navigation. It can re-evaluate the page on an RSC refetch, prefetch, refresh, or retry, and the manual --no-browser flow (where the verification URL is pasted into a browser) makes a second hit more likely. The first call authorizes the grant and finishes the CLI login. A second call then fails with FAILED_PRECONDITION because the request was already handled, and that error gets rendered as an alert.

This makes the completion idempotent: if the call fails with FAILED_PRECONDITION (code 9), we treat it as success rather than throwing. The grant already succeeded on the first call, so there is nothing to recover. This matches the existing pattern in idp/[provider]/success/page.tsx, which handles its one-time intent consumption the same way.

Test plan

• datumctl login --no-browser in prod completes without showing the error alert on /signedin
• datumctl login (auto-browser) still completes normally
• Denying consent on the device screen still works (it routes through the same server action)
• A genuine non-precondition failure still surfaces an error

Closes #89