fix: handle non-numeric error codes from Microsoft Graph in OAuth callback

[bgeihsgt]

Problem

When Microsoft Graph returns an error during OAuth profile fetch (e.g. HTTP 429 throttling), the JSON body contains a string error.code (e.g. "TooManyPendingRequests") rather than a numeric code. Passing this directly to Boom.boomify() as statusCode causes an AssertError crash because Boom requires a numeric value >= 400.

AssertError: First argument must be a number (400+): TooManyPendingRequests
  at internals.initialize (/emailengine/node_modules/@hapi/boom/lib/index.js:404:10)
  at exports.boomify (/emailengine/node_modules/@hapi/boom/lib/index.js:126:26)
  at handler (/emailengine/workers/api.js:2242:50)

Gmail is unaffected because Google APIs return numeric error.code values in their JSON error bodies (e.g. 403, 404). This bug manifests with Microsoft Graph (and potentially Mail.ru) because Microsoft uses string error codes like "TooManyPendingRequests", "TooManyRequests", "BadRequest", etc.

Fix

All three instances of the pattern in workers/api.js (Gmail, Outlook, and Mail.ru catch blocks) now check whether response.error.code is a valid numeric HTTP status code (number >= 400) before using it. If it's not numeric, the code falls back to the HTTP status code already captured on the error object (err.statusCode or err.oauthRequest.status), defaulting to 500 if neither is available.

This preserves existing behavior for Google APIs while correctly handling string error codes from Microsoft Graph and other providers.

Steps to Reproduce

1. Configure an Outlook OAuth2 app with Graph API base scopes
2. Initiate an OAuth connection for a mailbox that is being rate-limited by Microsoft
3. The /oauth callback handler crashes with AssertError instead of returning a 429

[CLAassistant]

All committers have signed the CLA.

[andris9]

Thanks! Next time, you can just send the stack trace, no need to come up with an actual fix 🙂