fix: short-circuit get_master_token() when master_token already stored

[githubhjs]

Problem

glocaltokens 0.7.6 has an early-return guard in get_master_token():

if self.username is None or self.password is None:
    return None  # (simplified)

This fires before the method checks whether master_token is already populated. As a result, when the integration is configured with a valid aas_et/... master token but an empty password (which is the case when users obtain the token via the browser OAuth / gpsoauth.exchange_token() workaround), every call to get_master_token() returns None and raises InvalidMasterToken — even though the token is sitting right there in self._client.master_token.

Fix

Short-circuit before delegating to the library: if self._client.master_token already holds a valid aas_et token, return it directly.

if self._client.master_token and is_aas_et(self._client.master_token):
    return self._client.master_token
return self._client.get_master_token()

is_aas_et is already imported in this file, so no new imports are needed.

Repro

1. Obtain a master token via gpsoauth.exchange_token() (needed because the standard Android login endpoint now returns BadAuthentication)
2. Configure the integration with master_token=<aas_et/...>, password=""
3. Without this fix: every coordinator refresh raises InvalidMasterToken
4. With this fix: token is returned correctly, devices are discovered and sensors update normally

Notes

• The root cause lives in glocaltokens — a fix there would be cleaner. This is a targeted workaround in api.py that unblocks users until the dependency is updated.
• Tested on ha-google-home v1.13.3 with glocaltokens 0.7.6.