Add-ons: Add-on purchase/availability statuses need better sync

[chriskmnds]

What

This issue is minor and likely a quick fix, but may also inform work with the features endpoint.

As of #64289 we determine the availability status of an add-on based on either:

1. Add-on purchased directly by user.
2. Add-on being part of a site's plan features.

We provide a different message for each case (despite this being subject to change i.e. have a single message for both cases).

The check is done in a custom hook (useAddOnAvailabilityStatus) and uses the site features selector (siteHasFeature). We need to revise the code for this as it behaves a little ambiguously right now. The siteHasFeature check will also account for products purchased on a given site (so case 2 above also becomes true when 1 is true). More so, I think this happens only in cases when product slugs map directly to feature slugs available for the given site - so for products not bundled as available features, this does not seem to be the case. In my brief tests with #64289 and a free site, it happens for "no ads", but not for "custom design" or "unlimited themes".

Check media/gif below. To reproduce, on a free site:

1. Go to /add-ons/[SITE_SLUG]
2. Purchase the "no-ads" add-on
3. Reload /add-ons and confirm the flicker/race condition between "purchased" and "included in your plan" that happens there

How

We need to revise the approach irrespective of how siteHasFeature works e.g. if we give precedence to "purchased" status, then probably best to wait for that API call to conclude before setting the "feature" status (else the behavior in the gif below occurs). Probably needs more testing/confirmation though as I'm a little 😵 right now.

Media

On reload, "included in your plan" shows for a brief second before "purchased" renders.

cc @dzver @obenland