Possible race condition in fetch setup

The code at

https://github.com/inrupt/solid-client-notifications-js/blob/bcb53a42392cdaea0987ddf6cf2d0fdd4bb5e02f/src/notification.ts#L93-L118

seems to suffer from 2 issues at first sight:

• The fetch member is temporarily set to crossFetch and there is no indication of the switch happening. So when accessing the object quickly after creation, an unauthenticated fetch might accidentally be used.
• There is no error handling. Even though the code says we "don't care" whether something errors (presumably because of the fallback to crossFetch), the promise rejection will still go unhandled and cause application errors/warnings. And I'd be surprised if we really don't care.

Both issues can be mitigated by temporarily assigning a function to this.fetch that stores all of its calls until the fetch object resolves. Something like:

const fetches = [];
this.fetch = (...args) => {
  return new Promise((reject, resolve) => {
    fetches.push({ args, reject, resolve });
  };
}

and then upon setting this.fetch, calling all fetches and resolve or reject depending on whether an error occurred or not.

This holding pattern can also be abstracted into a utility function.

Start by reading src/notification.ts lines 93-118, focusing on how fetch is initialized and switched to crossFetch. Trace calls made before initialization completes and how rejected promises are handled. Done means early calls are not unauthenticated and initialization failures do not become unhandled promise rejections.