fix(auth): keep a server-valid token when the SDK marks it expired — fixes login loop

The @hanzo/iam SDK's getValidAccessToken() returns null when the token-exchange
response carried no `expires_in` (the hanzo-cloud IAM app has no token lifetime set)
and no refresh token was issued — it flags the freshly-minted token expired even
though IAM accepts it (userinfo 200). That null dead-ended AccountApi.session() ->
account=null and looped /signin (~128 POST /login/oauth per minute). Fall back to the
raw stored token at the wrapper boundary; account.ts and the refresh timer are
unchanged (expiry still derived from the token's own exp).

src/lib/auth/iam.ts

@@ -97,7 +97,15 @@ export function iamAccessToken(): string | null {
 export async function iamValidAccessToken(): Promise<string | null> {
   if (typeof window === 'undefined') return null
   try {
-    return await iamSdk().getValidAccessToken()
+    const token = await iamSdk().getValidAccessToken()
+    if (token) return token
+    // The SDK marks a freshly-minted token "expired" when the token-exchange response
+    // carried no `expires_in` (an IAM app with no configured token lifetime) and no
+    // refresh token was issued — yet IAM still accepts the token (userinfo 200). Fall
+    // back to the raw stored token so a valid session is not discarded, which dead-ended
+    // AccountApi.session() -> account=null and looped /signin. The proactive-refresh
+    // lifetime is derived independently from the token's own `exp` (iamExpiresInSeconds).
+    return iamAccessToken()
   } catch {
     return null
   }