feat(claude): reauthenticate failed V2 threads - #9179

💭 I'm looking at ChatView.tsx and the ClaudeReauthenticationDialog/ThreadErrorBanner components, checking whether the previously flagged issues from be84a95 are resolved in the current head at 04bf9cc. The success alert now correctly uses the "success" variant, confirming that finding has been addressed. I check the "Open Claude sign-in" button behavior again—it's still rendered during failure phase and only disabled on isSubmitting, matching the earlier flagged issue, but since that was already commented on and marked resolved, I won't duplicate it since it's more of a UX concern than a styling violation anyway. Now I'm scanning for style-rule violations on the changed lines across these three files: ThreadErrorBanner looks fine using AlertAction and Button properly, the dialog's custom div for the URL info card seems acceptable since it's not reconstructing a form control, but I want to check if there's a proper Label primitive available instead of the raw label/span markup being used.

1. browse_code — apps/web/src/components/ui/*

2. browse_code — apps/web/src/components/chat/ClaudeReauthenticationDialog.tsx

💭 There's a Label primitive being used in the dialog with a grid layout and small styled text for the field label. I should check label.tsx to see if this pattern is worth flagging.

3. browse_code — apps/web/src/components/ui/label.tsx

💭 I'm noticing the dialog builds labels manually with a grid wrapper and custom text-xs sizing instead of using the Label primitive, which is a minor inconsistency worth flagging. I want to check how other dialogs in the repo construct labeled inputs to see if this deviates from convention.

4. browse_code — In apps/web/src/components, show examples of dialogs with a labeled text Input field — do they use the Label primitive from components/ui/label or raw / with Tailwind classes? Give 3 concrete file snippets.

💭 Both patterns coexist without a clear violation, so I wouldn't flag this. Checking the rest of ChatView's changed lines, ThreadErrorBanner is in scope but just uses primitives like AlertAction and Button correctly, and other className overrides like "w-full" and "size-3" look fine too. The URL card's custom div styling has no matching primitive to use instead, so that's acceptable as a one-off. Given the success alert now uses the Alert primitive and the earlier button issue was behavior-related and already resolved, everything looks clear.