OAuth Token Cache Breaks When Server Omits `token_type`

Description of the issue

TokenCache.update_data() throws an exception when the OAuth server response does not include a token_type field. While RFC 6749 Section 5.1 technically requires this field, many real-world OAuth servers — particularly internal/custom implementations and some token refresh responses — omit it, implicitly defaulting to Bearer. This makes Frappe's Connected App integration fail with any such server.

Context information (for bug reports)

Output of bench version

frappe 15.x.x (or develop branch)

Steps to reproduce the issue

1. Set up a Connected App pointing to an OAuth server that omits token_type from its token response
2. Complete the authorization flow
3. Observe the callback

Observed result

frappe.exceptions.ValidationError: Received an invalid token type.

The token is never stored. The Connected App integration is broken for that server.

Expected result

When token_type is absent, Frappe should default to "bearer" (the RFC implied default) and store the token successfully, matching the behaviour of oauthlib and requests-oauthlib.

Stacktrace / full error message

Traceback (most recent call last):
  File "frappe/integrations/doctype/token_cache/token_cache.py", in update_data
    frappe.throw(_("Received an invalid token type."))
frappe.exceptions.ValidationError: Received an invalid token type.

Additional information

Root cause:

# Current (BUGGY):
token_type = cstr(data.get("token_type", "")).lower()
# If token_type absent: "" → not in ["bearer", "mac"] → throws
if token_type not in ["bearer", "mac"]:
    frappe.throw(_("Received an invalid token type."))

Fix — default to "bearer" when absent:

# Fixed:
token_type = cstr(data.get("token_type", "bearer")).lower()
if token_type not in ["bearer", "mac"]:
    frappe.throw(_("Received an invalid token type."))

This matches the behaviour of oauthlib (the library Frappe already us