V48 Gate 3 (specification-implementation): confirm the reconnect fix live; harden button types; log the button-hang bug found along the way (V48-Gate3-F36)

Live-confirmed F35: disconnected via a direct fetch() DELETE from the
console (the UI Disconnect button was blocked — see F36), then reconnected
through Bitcode's normal Connect GitHub flow. Result: Connected/Valid. This
confirms the stuck row's installation id belonged to the other Bitcode
GitHub App and reconnecting against the currently-configured app resolves
it, no GitHub-side action needed.

Along the way, found a real, separate, still-open bug: the Refresh and
Disconnect buttons on this card don't respond to clicks at all (no dialog
opens, no console error, no network request, a brief whole-tab hang then
normal again) — ruled out as a server/API issue by confirming the exact
same endpoint works instantly when called directly. Documented the
investigation and ruled-out theories as V48-Gate3-F36 (open) so it isn't
re-investigated from scratch later.

Applied one zero-risk hardening regardless of root cause: both buttons now
set type="button" explicitly, since shadcn's Button doesn't default it and
a bare <button> falls back to the browser's native type="submit".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: geraldarthurdavis

BITCODE_V48_QA.md

@@ -546,8 +546,15 @@ Track 3-4 scripts (BTD ledger, settlement, pack journaling) get added when those
 - Refined cause: per the Environments section above (`## Environments`, corrected 2026-07-06), there are genuinely TWO separate Bitcode GitHub App registrations — `bitcode-github-auxillary` (production-mainnet) and `bitcode-github-auxillary-stag-test` (`GITHUB_APP_ID=4224019`) — and, per the 2026-07-05 "production == staging" decision, the stag-test app's credentials were pushed to ALL THREE Vercel targets (`staginglocal-testnet`, `production`, `preview`). A connection whose stored installation id was minted under `bitcode-github-auxillary` (e.g. from before that unification, or from a flow that used the production app's install link) is invisible to a JWT signed for `bitcode-github-auxillary-stag-test` — GitHub returns 404 for "this app doesn't own that installation id," which reads identically to "the installation was removed" even though the app is very much still installed (just the OTHER one). Confirmed can't rule this out by comparing `GITHUB_APP_ID` values directly: `vercel env pull` returns encrypted vars as empty strings under this session's CLI permissions (confirmed non-sensitive vars pull fine, so this is a permission gate, not empty config).
 - Repair: corrected `VCSConnectionCard.tsx`'s 40x hint — it no longer claims "the installation was removed, reinstalling will fix it" (unverifiable and, in this case, wrong). It now says a 40x means this connection's stored installation isn't one the CURRENT deployment's app can use, even if GitHub still shows an app installed, and suggests Disconnect (in Bitcode) + reconnect — which re-runs the install/authorize flow against whichever app this deployment is actually configured with (already shown as installed in GitHub's list) and writes a fresh installation id, with no GitHub-side action needed. Updated `uapi/tests/vcsConnectionCard.test.tsx` to match. Verified: `tsc --noEmit` 0; `vcsConnectionCard.test.tsx` 4/4 green.
 - Not yet done: confirming from the Supabase side which specific `connectionId`/app the existing stuck row actually points to (would need direct DB access, out of reach here) — Disconnect + reconnect is the actionable next step for the live account; if it does NOT resolve to Valid, the next lead is confirming this Preview deployment's actual `GITHUB_APP_ID`/`SUPABASE_URL` pairing against the documented map above.
+- **CONFIRMED (2026-07-08, live)**: disconnected via a direct `fetch(..., {method:'DELETE'})` from the browser console (the UI Disconnect button itself was blocked — see F36), then reconnected through Bitcode's normal Connect GitHub flow. Result: **Connected / Valid.** This confirms the diagnosis — the stuck row's installation id belonged to the OTHER Bitcode GitHub App; reconnecting against the currently-configured app resolved it, no GitHub-side action needed. `/deposits`' Branch/Commit reconnect-required banner (F32) should now be gone for this account too, since it shares the same `connectionStatus.valid` gate.
 
-## Track 1 — Identity / Authentication / Auxillaries — COMPLETE 2026-06-12 (email deferred by decision; F2/F9 and legacy eradication queued for gates)
+### V48-Gate3-F36 — Refresh and Disconnect buttons on the GitHub connection card don't respond to clicks; the underlying API works fine (OPEN)
+
+- Severity: medium (workaround exists — the same actions can be driven directly via `fetch()` from the console — but the UI affordances for two of the four card actions are dead).
+- Observed (2026-07-08, live): clicking **Disconnect** never opened its confirmation `AlertDialog` at all (confirmed explicitly — no dialog appeared). Clicking **Refresh** produced no visible change either. Both: no console errors, no Network tab entries for the click (not even a pending request), a brief whole-tab "hang" that self-resolves, then the page is normally responsive again. A hard reload did not change the behavior. Incognito (rules out an interfering browser extension) was not tested at the user's judgment call.
+- Ruled out during investigation: NOT a server/API problem — calling the exact same endpoint directly from the console (`fetch('/api/vcs/github/connection', {method:'DELETE'})`) succeeded instantly with a clean response. This isolates the bug to the click → handler path in the browser for these two specific buttons (both plain `<Button onClick=...>` and the `AlertDialogTrigger`-wrapped one), not to `handleRefresh`/`handleDisconnect`'s own logic or the route they call.
+- Investigated and NOT confirmed as the cause (documented so this isn't re-litigated): (a) Radix `AlertDialog` nested inside Auxillaries' own custom `createPortal`-based overlay — plausible stacking/portal interaction, but Auxillaries can also render as a dedicated non-modal route, unconfirmed which applies here; (b) neither the "Refresh" nor "Disconnect" `<Button>` sets an explicit `type="button"` (shadcn's `Button` does not default it, so a bare `<button>` inside a `<form>` defaults to `type="submit"`) — but no `<form>` ancestor was found in this card's actual render tree (`VCSIntegrationPanel` → `Tabs` → this card; the sibling "Personal Access Token" tab does have its own `<form>`, but as a sibling `TabsContent`, not an ancestor, so it shouldn't matter — worth setting `type="button"` explicitly anyway as a zero-risk hardening, defensive habit regardless of whether it's the cause here); (c) `AnalyticsEventsClient.tsx`'s global capture-phase `document.addEventListener('click', handler, true)` GA4 click tracker — a plausible collision point for a delegated capture-phase listener, but its own logic is a small bounded DOM walk + a defensively-wrapped no-op-when-unloaded `gtag()` call, nothing that should itself hang.
+- Next steps (not done — needs live repro access this session didn't have): reproduce with React DevTools Profiler recording to see if a render is actually happening during the "hang" window; check whether the same card, freshly mounted after a full reconnect-triggered page reload, still exhibits the same behavior (untested — the user's remaining verification was done via the direct-fetch workaround, not by retrying the buttons post-reconnect); check Chrome's Task Manager (Shift+Esc) for CPU during the hang to confirm/deny a compute-bound cause vs. something else entirely. — Identity / Authentication / Auxillaries — COMPLETE 2026-06-12 (email deferred by decision; F2/F9 and legacy eradication queued for gates)
 
 - [x] Sign up / sign in via Connect Wallet (nav CTA → SignUpWindow → wallet signature on testnet4 → `custom:bitcode-bitcoin` session → `/tps/supabase/callback`) — verified 2026-06-12 after F5 fix; lands on `/packs`. Re-verified from fully nuked state (purged user + cleared site data): created 19:29:21 → session 19:29:25 → binding auto-written 19:29:29 by the bridge on `/packs` mount with no Auxillaries visit; UI consistent across nav, Wallet, and Profile panes.
 - [x] Wallet binding persisted after sign-in — verified 2026-06-12: identity-derived bind populated `username` (`wallet_tb1p6x70u8ag`) and the full `walletBinding` (address, provider `leather`, network `testnet`, status `pending`, `proofKind: provider_session`, `boundAt` stamped on bridge mount). `payment_address`/`addressType` stay null in identity-derived binds (GoTrue drops the custom claims); they backfill via the in-panel signature flow, which settlement-adjacent actions require anyway.

uapi/components/base/bitcode/vcs/VCSConnectionCard.tsx

@@ -263,7 +263,15 @@ export function VCSConnectionCard({
             )}
 
             <div className="flex gap-2">
+              {/* V48-Gate3-F36: explicit type="button" — shadcn's Button doesn't
+                  default one, so a bare <button> falls back to the browser's
+                  native type="submit". No <form> ancestor was found for this
+                  card, so this shouldn't currently matter, but it's a
+                  zero-risk hardening against exactly that class of bug (a
+                  click "doing nothing"/submitting instead of firing onClick)
+                  regardless of whether it's the cause of the live hang. */}
               <Button
+                type="button"
                 variant="outline"
                 size="sm"
                 onClick={handleRefresh}
@@ -272,10 +280,11 @@ export function VCSConnectionCard({
                 <RefreshCw className={`mr-2 h-4 w-4 ${isRefreshing ? 'animate-spin' : ''}`} />
                 Refresh
               </Button>
-              
+
               <AlertDialog>
                 <AlertDialogTrigger asChild>
                   <Button
+                    type="button"
                     variant="outline"
                     size="sm"
                     disabled={isDisconnecting}