[Woo POS] Stop `GhostableCardView` rendering, and network requests when there are no new items

[iamgabrielma]

Description

This PR makes the GhostableCardView to only rely on isLoading state in order to render, as well as marking the last page when no new unique items are fetched from the remote. This resolves two issues:

• The GhostableCardView will no longer render indefinitely when we reach the end of the item list
• We stop doing network requests unless we reload the item list, in which case isLastPage resets.

Caveat: I think there’s a compromise to be made with our current limitations on eligible products: if there’s a gap in the API response between eligible products we might trigger the “last page” too early (this is easily reproducible if we limit products per page to something like 5, and then there's 5+ non-eligible products in the request).

We can see this in the video below where the GhostableCardView doesn't render for a second if there's a gap, but then we immediately fetch next page, it has items, so loads the rest normally. This should not be a problem in release, as would imply that the merchant has a 100+ product gap that are not eligible between page fetches. This can be improved in the future as needed, but any advice or recommendation of how to handle it better is welcome.

Update: these have been resolved in the latest iteration

https://github.com/user-attachments/assets/4b6fb126-1037-49f9-98bd-bf0eef3ae62f

Steps to reproduce

• With a POS eligible store, for simplicity modify POSConstants.productsPerPage to something like 5 or 10, and load POS
• Scrolling down should show the GhostableCardView while there are more items to fetch
• At the end of the list, the GhostableCardView should disappear
• Pull-to-refresh should reload the 1st page normally, scrolling down should show the GhostableCardView while there are more items to fetch, and stop at the end of the list.
• If we have a store with 1-2 products, the GhostableCardView will also stop as soon as the end of the page is triggered ( you can create a new jurassic ninja site with 1 simple product, or I can send access to a test site if needed 👍 )

---

• [x] I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• [x] The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• [x] Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• [x] Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on all devices (phone/tablet) and no regressions are added.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS
	Build Number	pr14382-2113b1b
	Version	21.1
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	2113b1b9f4452042fc4942b0c8867faee5669b95
	App Center Build	WooCommerce - Prototype Builds #11613

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[iamgabrielma]

Thanks for the review and the pairing @joshheald , this is ready for review when you have the chance. No logic has been changed since yesterday except for this commit, which checks we're not throwing the out of range error if we just happen to have no eligible products at all.

https://github.com/user-attachments/assets/cf2b1579-02ce-47d3-bd62-ae1e5f3f4d82

When cleaning up the loadNextItems() method here https://github.com/woocommerce/woocommerce-ios/pull/14382/commits/8956c01a42484791edcd27bc1c6876c7c2fad267 on my testing I could see the behaviour was exactly the same, however some tests started to fail because expected .empty but received .loaded([]) instead, so I reverted it for now, this can be done separately once the design/arch changes are completed.

[iamgabrielma]

Thanks tidying up things and merging, appreciated!

I didn't write an extra test for the initialPageLoad cases here; perhaps that would be worthwhile to do next week?

Definitely. Logged here: https://github.com/woocommerce/woocommerce-ios/issues/14441

I found a "fun" edge case...If the first page of results doesn't have any products that pass the filter, we show the empty state... but that means we never load page 2 even if it might have something.

Yes, I think we could try triggering a couple of subsequent pages automatically to address this edge case, or perhaps offer a "retry" button that does this. It would be a better experience than getting stuck without knowing why. Logged: https://github.com/woocommerce/woocommerce-ios/issues/14442