Right now ProfileSyncServiceFactory declares dependencies for all of the BrowserContextKeyedServiceFactories that ChromeSyncClient accesses. This seems like it should make sense because ChromeSyncClient is directly owned by the ProfileSyncService, and as long as the ProfileSyncService is alive, then ChromeSyncClient may be accessing these factories to retrieve various SyncableServices/SyncBridges by model type.

However, to access the SyncableService for SUPERVISED_USER_WHITELISTS, we go through the SupervisedUserServiceFactory, which wants to depend on the ProfileSyncServiceFactory. This is because in SupervisedUserService::Init() it seemingly wants to call ProfileSyncService::AddPreferenceProvider() to control forced/preferred types.

It doesn't immediately seem unreasonable to me that a model type's chrome/browser/* logic would want to interact with the PSS. I'm not sure what a good solution here looks like.

Historically we thread jumped with the Profile object and accessed BrowserContextKeyedServiceFactories on the wrong thread, but https://codereview.chromium.org/2769113002/ should remove that quirk, hopefully. It may be possible that we just drop all the deps of the PSS and just null check everything before we use it?