Add an optional check for unready entry points waiting for private API consumed as public

[itsh01]

Add verifyPendingEntryPointsAPIsMismatch method

Summary

Adds a method to detect when pending entry points are waiting for private APIs that will never be available due to public/private mismatches.

Changes

• Added verifyPendingEntryPointsAPIsMismatch() to AppHost interface
• Implemented detection logic that checks ready APIs against pending dependencies
• Throws descriptive error when private APIs are being consumed as public
• Added test coverage for the mismatch scenario

Why

Prevents entry points from getting stuck waiting for APIs that will never be available, making dependency issues easier to debug during development.

Why not in repluggableAppDebug

This could be useful for runtime in certain cases, though not out of the box, since the loading flow should be controllable, e.g. for 2 phases of entry points loading, maybe the consumer will want to run it after the second phase, in production environment

[zonzujiro]

Error message should have a mention of function that can be used to detect reason of the error - verifyPendingEntryPointsAPIsMismatch in this case

[itsh01]

Currently it is manually triggered when you call verifyPendingEntryPointsAPIsMismatch and not automatically, as mentioned, to allow cases of multi staged loading (and also, I wouldn't want to run it after every batch of entry points, to avoid undesired performance overhead).
Do you imagine the manually triggered error directing you to run this check again?

[zonzujiro]

Ah, I thought you always doing this check. In such a case, it's quite opaque flow - one needs to be aware of this difference between how repluggable handles entries with and without public properties. And as a consequence know about this utility.

So I believe in the future someone can face similar problem and will not know what to do.

[itsh01]

That's fine, since it's the app's responsibility rather than Repluggable's, since only the app knows what's the loading sequence and thus know when to run the verification.
We need to add the complementary call in the client code where we think it's most appropriate.