fix(invite): hold the loading state until the stored token resolves (#6488)

Two gaps left by #6486.

The query was gated on isTokenResolved but the loading state was not. With
enabled: false React Query still reports success when the key already holds
data, so a cached null-token entry made isPending false and rendered the accept
UI for one frame before the effect applied the stored token. Reachable only on a
client-side remount after a tokenless fetch already succeeded.

An empty ?token= also stopped falling back to storage: searchParams.get returns
'' which is not null, so token became '' where the pre-#6486 truthiness check
had read sessionStorage. Normalize to null at the source.

apps/sim/app/invite/[id]/invite.tsx

@@ -286,7 +286,8 @@ export default function Invite({ registrationDisabled }: InviteProps) {
   const isNewUser = searchParams.get('new') === 'true'
   const errorReason = searchParams.get('error')
   const urlError = errorReason ? getInviteError(errorReason) : null
-  const tokenFromQuery = searchParams.get('token')
+  /** `|| null` so an empty `?token=` falls back to storage rather than querying with ''. */
+  const tokenFromQuery = searchParams.get('token') || null
   /**
    * Derived during render so the invitation query key is correct on the first
    * commit; an effect-set token refetches under a second key whenever the
@@ -308,7 +309,7 @@ export default function Invite({ registrationDisabled }: InviteProps) {
   })
   const invitation = invitationQuery.data?.invitation ?? null
   const joinPreview = invitationQuery.data?.joinPreview ?? null
-  const isLoading = Boolean(session?.user) && invitationQuery.isPending
+  const isLoading = Boolean(session?.user) && (!isTokenResolved || invitationQuery.isPending)
 
   const fetchError = invitationQuery.error
     ? getInviteError(