fix(AdminGuesser): respect passed loading prop in AdminGuesser

[djaszak]

Q	A
Branch?	main
Tickets	Partly closes #632
License	MIT
Doc PR	api-platform/docs#...

This PR aims to fix the problem of not being able to override the used <Loading /> component in the <AdminGuesser /> component. The <AdminGuesser /> already accepts an alternative <Loading /> component, so using it just seems natural. It partly fixes the related issue of it being non-translated, as one can pass a component with either no description or some hard-coded string or similar

[Copilot]

Pull request overview

Fixes AdminGuesser so the loading prop (custom loading component) is actually respected during the initial introspection loading phase, aligning behavior with the existing AdminProps contract and helping address issue #632.

Changes:

• Default/destructure loading as a LoadingPage component and render it during initial loading state.
• Propagate the same LoadingPage component down to AdminResourcesGuesser via loadingPage.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The behavior change (using the caller-provided loading component during the initial introspection load) isn’t covered by tests. Current AdminGuesser.test.tsx uses shallow rendering, so it won’t run useEffect or exercise the if (loading) return <LoadingPage /> branch with a custom loading prop. Add a test that mounts AdminGuesser (e.g., with @testing-library/react) and asserts that a custom loading component is rendered before dataProvider.introspect() resolves.