The authentication errors are not persisted by Chrome in the token service, but they are persisted in profile attributes entries.

They are used from a single place:
ProfileMetrics::CountProfileInformation

The current implementation is very subtle and fragile, and we are lucky that it works.

Here is the flow for an account in authentication error:
1) Chrome starts. The token service has no error, but the profile entry has an error.
2) the profile entry starts listening to changes in token errors, but does not update its current state. At this point the state of the profile entry does not reflect the state of the token (which is not intended). Token service and profile entries remain out of sync, but will converge on the next error change.
3) the auth error is recorded based on the profile entry, which indicates correctly the error.
4) Token error is detected (either when loading the tokens, or when a service tries to use the token). At this point the token service and the profile entry are consistent and will remain consistent.

There are multiple problems:
- in 2, it is not intended that the token service and the profile entry are inconsistent.
- it is not clear when the profile metric must be recorded, and what it means on startup. Chrome assumes that all auth errors have disappeared on startup, so that seems to be a very bad time to record them.