OAuth credential sync and app integration enhancements

Hi there 👋

This PR introduces OAuth credential syncing across multiple app integrations. The review uncovered systemic security and correctness issues affecting nearly every integration. Several OAuth handlers lack proper state validation, error handling, and input sanitization. Token refresh logic is inverted in multiple apps, causing either stale token usage or unnecessary refreshes. Serverless race conditions exist from module-level mutable state, and type mismatches between sync endpoints and their callers will cause runtime failures. These findings should be addressed before enabling credential sharing in production.

Must fix

• 🔴 parseRefreshTokenResponse.ts (L10)
  Invalid Zod computed property keys: [z.string().toString()] evaluates to literal string 'String' at runtime, not a dynamic catch-all key.
• 🔴 parseRefreshTokenResponse.ts (L28)
  Hardcoded sentinel value 'refresh_token' silently substituted when OAuth response lacks refresh_token. Overwrites valid stored refresh tokens, permanently breaking all subsequent OAuth refreshes.
• 🔴 decodeOAuthState.ts (L8)
  Unhandled JSON.parse on state parameter — malformed state causes uncaught exception. Also a DoS vector via crafted state strings.
• 🔴 app-credential.ts (L22)
  No HTTP method restriction — webhook endpoint accepts any method. Only POST should be accepted per REST conventions and CSRF prevention.
• 🔴 app-credential.ts (L57)
  Unhandled exception in JSON.parse(symmetricDecrypt(...)) — corrupted data causes 500 with stack trace instead of proper error response.
• 🔴 app-credential.ts (L57)
  No runtime validation on decrypted OAuth keys — malformed or tampered data silently corrupts stored records.
• 🔴 googlecalendar/CalendarService.ts (L98)
  parseRefreshTokenResponse returns entire Zod SafeParseReturnType object instead of just data. This corrupts stored credential keys with {success, data, error} wrapper.
• 🔴 googlecalendar/CalendarService.ts (L86)
  Type mismatch when APP_CREDENTIAL_SHARING_ENABLED is true: refreshOAuthTokens returns a Response object, but code accesses res?.data (undefined).
• 🔴 hubspot/CalendarService.ts (L115)
  Token validity check inverted: condition treats expired tokens as valid and valid tokens as expired — refresh never triggers.
• 🔴 hubspot/api/callback.ts (L22)
  No handling for OAuth authorization denial — if user refuses, the callback crashes with undefined access.
• 🔴 hubspot/CalendarService.ts (L262)
  Module-level hubspotClient singleton is mutated on each request — race condition in serverless environment.
• 🔴 office365calendar/CalendarService.ts (L490)
  Impossible condition status < 200 && status >= 300 (should be ||) — all error status codes silently accepted as success.
• 🔴 office365video/VideoApiAdapter.ts (L65)
  Missing parseRefreshTokenResponse validation for credential sync — uses raw response without validation.
• 🔴 salesforce/CalendarService.ts (L1)
  Missing import for prisma — ReferenceError at runtime when credential sync code path executes.
• 🔴 salesforce/CalendarService.ts (L84)
  Token refresh reads old credentials (stale token) instead of using current stored credentials — unnecessary refreshes.
• 🔴 webex/VideoApiAdapter.ts (L38)
  Token validity check inverted: expired tokens treated as valid, valid tokens treated as expired.
• 🔴 webex/VideoApiAdapter.ts (L27)
  Schema uses z.date() for start/end times but Webex API returns ISO 8601 strings — Zod parse failure.
• 🔴 zoho-bigin/CalendarService.ts (L89)
  credential.id (database primary key) passed as userId instead of credential.userId — sync broken.
• 🔴 zohocrm/CalendarService.ts (L131)
  Token validity check inverted: refresh skipped when needed, expired tokens used.
• 🔴 zohocrm/CalendarService.ts (L168)
  Expiry calculated as 3600 ms instead of 3600 seconds — token expires after 3.6 seconds instead of 1 hour.
• 🔴 zoomvideo/api/callback.ts (L10)
  OAuth state parameter not validated in callback — no CSRF protection. State should be compared against stored value.
• 🔴 larkcalendar/CalendarService.ts (L289)
  getAvailability sends ISO 8601 date strings but Lark freebusy API expects Unix timestamps in seconds.
• 🔴 stripepayment/api/callback.ts (L23)
  No validation that code is present — if undefined, stripe.oauth.token() crashes with uncaught error.
• 🔴 tandemvideo/api/callback.ts (L55)
  No HTTP response sent when OAuth token exchange fails — client connection hangs until timeout.
• 🔴 tandemvideo/api/callback.ts (L9)
  Module-level let variables mutated on each request — race condition in serverless environment.

Should address

• 🟡 encodeOAuthState.ts (L5)
  EncodeOAuthState is a no-op — returns input unchanged. Provides no actual security validation.
• 🟡 larkcalendar/api/add.ts (L39)
  Fire-and-forget fetch without error handling or await — unhandled promise rejection on failure.

Minor

• 🔵 constants.ts (L103)
  APP_CREDENTIAL_SHARING_ENABLED env var not coerced to boolean — returns string "true"/"false" instead of actual boolean.
• 🔵 turbo.json (L207)
  CALCOM_WEBHOOK_SECRET listed out of alphabetical order in turbo.json configuration.